我们正在为公司共享驱动器的权限添加许多新组。一些文件夹树可以包含数百万个文件和数 TB 的数据。照这样来看，更改这些文件夹的 ACL 可能需要几秒到几小时的时间，具体取决于当前树中的文件数量。
我们希望能够在工作日进行这些更改，但前提是安全的。
几个问题，
- 如果您更改某个文件夹的权限，而该文件夹的子文件夹继承了该权限，则在 ACL 更改期间在树中创建文件时是否可以保持一致性？
- 假设您从不删除访问权限，而只是向 ACL 添加新组，那么是否需要对打开的文件采取额外的注意？
- Set-ACL Powershell 命令行程序的行为是否与属性 > 安全 > 高级页面相同？
例如，如果有一棵树上有 20,000 个文件，并且假设需要十分钟才能更改所有 NTFS 权限... 如果用户在此窗口期间在子文件夹中创建文件，会发生什么情况？ 此文件的权限是否会缺少我们授予访问权限的新组？
感谢您的任何建议或意见！
答案1
如果您更改某个文件夹的权限，而该文件夹的子文件夹继承了该权限，则在 ACL 更改期间在树中创建文件时是否可以保持一致性？
我的理解是，此操作不是事务性的，这意味着权限是连续更改的。这样，如果您开始更新，根目录将具有与其后代不一致的权限，并且在此期间它们的行为将有所不同。我已经。无法保持一致性。
假设您从不删除访问权限，而只是向 ACL 添加新组，那么是否需要对打开的文件采取额外的注意？
我不这么认为，特别是如果你只添加权限。
Set-ACL Powershell 命令行程序的行为是否与属性 > 安全 > 高级页面相同？
再次，根据我的理解，他们会做出同样的行为。
答案2
应该没问题。继承向下流动。首先使用新的 ACL 更新目录，然后更新目录中的文件。
当用户创建文件时，如果目录已经继承了新的 ACL，则将使用该新 ACL 创建文件。如果目录尚未继承，则一旦继承到达该文件夹，文件将自动更新。
这不考虑微软软件中的任何错误或怪癖。我重做 ACL 的频率不够高，因此无法确信它每次都能完美运行。