我们的应用程序使用一个组件，该组件在我们的可执行文件的目录中需要一个许可证文件，这恰好是一个.NET WinForms应用程序，尽管我认为这个问题并不重要。当安装在某些XP专业版机器上时（目前为止只有几百个中的三个），该组件会抛出许可证异常。因此，我重新生成了许可证文件并将其发送给组件供应商（EMC Captiva），供应商声称该错误是由于“Users”组对该文件没有读取权限。遇到错误的用户恰好是本地管理员，但除此之外我仍然对更一般的问题感到好奇。
所以我的问题是，ACL是否存储在一个文件中，以便它们在整个生命周期中都遵循该文件，特别是在我的开发机器（机器1）上生成许可文件，存储在Subversion（机器2）中，检出TeamCity（机器3）的源代码控制，由InstallShield（机器4）打包到安装程序中，最后部署到客户机器（机器5），由管理员安装它？在我的开发机器（机器1）上生成文件后，通过其支持站点（机器2）将其上载到组件供应商，然后支持人员将其下载到他们的机器上进行检查（机器3）？
我不确定这一点（这就是我在这里问的原因），但我假设每台Windows机器都将ACL存储在NTFS管理的某个中心目录/ list / table中，而不是存储在文件中。当原始文件的ACL从一台机器复制到另一台机器，存储在Subversion中，打包成MSI等时会发生什么？有人能指点我一些好的参考资料，我可以在这里阅读吗？
答案 0 :(得分：14)
ACL存储在执行所有后台管道的NTFS分区中 - MFT（主文件表）。
ACL不跟随文件，因为它不是文件的一部分（就像它是文件名元数据一样）。该文件可以跨越分区类型边界（NTFS-> FAT），ACL不能。
现在，如果您在一个NTFS分区中移动文件，您可能会得到ACL实际上遵循该文件的印象。这是因为在移动期间，实际上只改变了MFT中的文件名。其他一切都保持不变。
如果您复制文件或将其移动到另一个分区或计算机（实际上是一个复制+删除操作），复制的文件将默认继承其新容器的权限（仅限可继承的容器）
但是，有些工具能够在复制操作之后保留文件的ACL（简单地通过在复制操作之后在目标文件上重新创建它），甚至可以在分区或计算机边界上。 xcopy可以做到这一点。
但是由于ACL可以包含“域拥有”的SID，因此ACL条目实际上对于不属于同一域的目标计算机实际上没有意义（例如，将NTFS格式化的USB驱动器带回家时） 。在这种情况下，ACL条目将不起作用。
其他SID“众所周知”，如“SYSTEM”SID。这些实际上将跨域边界识别。