VVS*_*VVS 9 networking ntfs acl file-permissions
有时，我们会遇到文件的权限与其所在文件夹不同的问题。
现在我发现有一篇知识库文章解释了这背后的原因：
默认情况下，对象从其父对象继承权限，无论是在创建时还是在将其复制或移动到其父文件夹时。当您将对象移动到同一卷上的不同文件夹时，会发生此规则的唯一例外。在这种情况下，将保留原始权限。
因此，用户将文件从一个文件夹移动到另一个文件夹，并保留了原始文件夹的权限。
我现在的问题是：为什么会存在这个异常？这背后的原因是什么？
小智 8
我在一篇博客文章中解释了这一点http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-permissions/但它下面也进行了说明。
复制文件时，它必须创建一个全新的文件并为其分配一组新的权限，因此如您所知，它会从父文件夹中获取权限。
当一个文件被移动到另一个卷时，实际发生的是它被复制到新卷并删除旧文件。因此，重复上述相同的过程，因为它又是一个新文件并且需要设置权限。
当文件在同一个卷中移动时，实际上什么都没有发生（在磁盘级别）。它只是更改文件的逻辑路径位置。磁盘上的实际数据和物理文件没有被触及或改变。有没有注意到当您将 5GB 文件移动到同一驱动器上的另一个文件夹时，它几乎是立即完成的？这就是原因，因为它实际上并没有移动，但指向文件逻辑存在位置的指针已更改。因为它没有以任何方式修改，所以权限也不会改变。
这就是这种行为的原因。
编辑：我忘了提及... MS 文章并不完全准确。MS报价：
默认情况下，对象从其父对象继承权限，无论是在创建时还是在将其复制或移动到其父文件夹时。当您将对象移动到同一卷上的不同文件夹时，会发生此规则的唯一例外。在这种情况下，将保留原始权限。
以上引用仅适用于已被授予明确定义的秒权限（关闭继承）的对象。正如我在评论中提到的，这一切都是为了尽可能保持 ACL 条目的效率。考虑以下示例：
为简单起见，假设您将文件夹设置为仅允许用户修改权限。在此之下，有数以千计的文件，但没有一个具有明确的权限设置。为每个文件创建 ACL 不是很有效，因为它们是完全相同的权限，因此它为文件夹设置了一个 ACL 条目。下一点是非常重要的理解；文件本身没有 ACL 权限。因此，当您将这些文件中的任何一个移动到同一卷中的新文件夹中时，MS 声称权限会随之移动（如上引用）。问问自己这个……怎么样？文件上没有首先移动的权限。这实际上是不正确的，我现在只是对其进行了测试以确认它。假设您要将文件移动到的目标文件夹具有权限，仅允许每个人组修改权限。那么由于该文件没有直接的 ACL，它继承了父文件夹的 ACL。这意味着权限已从用户修改（旧文件夹）更改为所有人修改（新文件夹）。
注意区别？？这一次，将文件移动到同一卷中的另一个文件夹实际上已经改变了权限，MS 说它没有这样做。自 2000 年以来，我是否刚刚在 MS 文档中发现了一个错误，哈哈？
现在看看使用显式权限时的相同场景。如果您对此文件夹中的文件设置显式权限（继承关闭），例如，拒绝用户读取访问权限，它现在会专门为此文件创建一个新的 ACL 条目。现在，当您将文件移动到新位置时，它有一个与其直接相关的 ACL 条目。在这种情况下，将文件移动到同一卷中的新位置会保留其权限（正如 MS 声称的那样）！
当您在同一个卷中移动文件时，您通常是在重新安排您的文件系统。在移动操作完成时，更改目录级别的文件权限可能会将您锁定在该文件之外。例如，如果您不小心将文件移动到系统或具有特殊所有权权限或以其他方式受保护的文件夹，则这是不可取的。除了获得文件的所有权（如果您有权限）或使用特权帐户登录之外，没有其他方法可以纠正错误。考虑到计算机的正常日常操作，您会发现您无法控制您的文件系统。
这种行为在大多数（如果不是全部）使用 ACL 的操作系统中很常见。它保证用户和应用程序在卷内进行正常的文件系统操作。
相反，在卷之间移动文件时，您通常会放弃文件以供某些人或其他人控制。正如您所了解的那样，文件包含目标文件夹权限是有道理的，这将为目标提供必要的权限，然后按照他们认为合适的方式重新排列自己的文件系统。
当然，这并不总是可取的。为此，可以使用特殊权限继承规则定义移动和复制操作。来自同一篇文章：
要在复制或移动文件和文件夹时保留权限，请使用带有 /O 或 /X 开关的 Xcopy.exe 实用程序。对象的原始权限将添加到新位置的可继承权限中。
若要在复制或移动对象时将对象的原始权限添加到可继承权限，请使用带有 –O 和 –X 开关的 Xcopy.exe 实用程序。