在我们的几个开发人员工作站上，我们已经得到了可怕的“这个访问控制列表不是被规范化的forms，因此不能被修改”。 我们尝试设置某些文件夹的权限时发生错误。 我们还没有弄清楚什么是破坏这些ACL。
现在，我知道解决它的唯一方法是右键单击损坏的文件夹/文件，select属性，然后单击安全选项卡。 Windows将会注意到这个错误，并提供修复它的方法。 我不喜欢这个，因为它是手动的，并要求用户做一些调查，找出什么文件夹/文件损坏。
是否有脚本或程序会自动执行此操作？ 我看到icacls有一个/verify参数，但它只是告诉我一个文件/文件夹的ACL已损坏。 它不提供修复任何东西。
您可以尝试使用一个简单的PowerShell脚本来覆盖另一个文件的acl的中断文件acl： get-acl path_to_file_with_known_good_acl | set-acl -path path_to_corrupt_file get-acl path_to_file_with_known_good_acl | set-acl -path path_to_corrupt_file
我终于能够为此自动修复。 当您调用PowerShell的Set-Acl cmdlet时，它将正确地重新排列ACL：
$path = C:\Path\To\Item\With\Borked\ACL $acl = Get-Acl $path Set-Acl $path $acl
当然，它可能是目录的父母搞砸了，所以你应该做一些遍历find罪魁祸首。 使用icacls C:\Path\To\Item\With\Suspect\CL /verify找出是否需要修复。
在我们的环境中，Cygwin可能是罪魁祸首：当它创build目录时，它喜欢对它们赋予POSIX风格的权限，而不是依靠Windows来pipe理文件系统的安全性。
对我来说，有两个麻烦：非规范的ACL +错误的规则声明NULL SID（WTH？）。 我build议这是由cygwin版本的git引起的。
无论如何，在我的情况下重新应用相同的 ACL没有任何意义：
> Set-Acl $f.FullName (Get-Acl $f.FullName) > (Get-Acl $f.FullName).AreAccessRulesCanonical False > (Get-Acl $f.FullName).GetAccessRules($True, $False, [System.Security.Principal.NTAccount]) | ? {$_.Identityeference.Value -eq "NULL SID" } FileSystemRights : WriteExtendedAttributes, ExecuteFile, DeleteSubdirectoriesAndFiles, ReadPermissions AccessControlType : Deny IdentityReference : NULL SID IsInherited : False InheritanceFlags : None PropagationFlags : None
所以我不得不从文件中明确地应用ACL，正如@mschneider所提到的那样
icacls也可以修复它：
c:\> accesschk -q FILE Error: FILE has a non-canonical DACL: Explicit Deny after Explicit Allow c:\> icacls FILE /t /q /c /reset Successfully processed 1 files; Failed processing 0 files c:\> accesschk -q FILE .. OK
其他方便的命令，相当于chmod 0777 FILE，chown root FILE
icacls FILE /t /q /c /grant :r Everyone:F icacls FILE /t /q /c /grant :r Everyone:F /inheritance:r icacls FILE /t /q /c /setowner Administrators