.net 在大型网络文件系统上快速设置可继承的ACE

我有一个关于网络文件系统上的ACL的问题

基本上，我想对一个顶层文件夹对象设置权限，该对象下面可能有100000多个文件和文件夹对象。我希望权限可以通过所有子文件夹和子文件继承（即“应用于文件、文件夹和子文件夹”为true）

我不想丢弃任何现有的可继承权限（即“用此对象的可继承权限替换所有子对象权限”为false）

因此，当我运行Set ACL、SetACL.exe、XCACLS.vbs，甚至使用Windows GUI时，完成该过程需要很长的时间——显然是由于子目录太大

我现在已经习惯了，但是：

我想知道-这到底是为什么

一天结束时，我不是只在一个文件夹对象上写一张ACE吗

• 我没有遍历目录
• 我没有修改子文件和文件夹上的单个ACL（我不认为）；及
• 我不是在替换权限

我假设如果您访问子文件夹/文件对象，它会检查它的显式ACE以查看您是否拥有权限，如果您没有权限，它会检查可能授予您访问权限的任何可继承权限（来自父文件夹对象）

那么，设置可继承权限是否也会导致将新的单个ACE写入每个子文件和文件夹，即使从技术上讲，您只在顶层设置一个ACE

是否有任何方法可以在顶层设置ACE，而不必使用命令遍历整个子目录？我希望在大量的文件和文件夹上快速高效地完成这项工作

我希望这是有道理的。期待任何建议

Rhys.

继承的权限（如显式）在标志位字段（）中安全描述符的位掩码中的文件夹/文件级别设置。这就是为什么在父文件夹级别设置传播到子文件夹（继承）的权限可能很长，这取决于受影响的子文件夹数量

基于此，答案是否定的：您不能在顶层设置ACE，也不能使用命令遍历整个子目录

---

您可以测试以编程方式在所有子项上设置显式acl是否比继承过程更快。

谢谢您的回复。我看了一下，它似乎有一个/NOPROPAGATE标志，使用的是旧的安全API..？是的。但这就像在安全选项卡上取消选中标记，以便在子项上不执行继承。测试fileacls.exe的速度，可能比set-acl cmdlet更好。是的，我也玩过它。我认为最终没有真正的解决方法，我只能等待脚本修改所有子文件夹和文件上的ACL。我正在研究使用powershell远程处理将处理过程一次卸载到不同的服务器上，看看是否可以更快地完成。我还看到了使用.NET 4.5和PowerShell 3的一些显著性能改进，这是一个积极的迹象。谢谢你的帮助：）