我们的应用程序使用的组件需要在可执行文件的目录中包含许可证文件，该文件恰好是 .NET WinForms 应用程序，尽管我认为这对这个问题并不重要。当安装在某些 XP Pro 计算机上时（迄今为止仅数百台计算机中的三台），该组件会引发许可证异常。因此，我重新生成了许可证文件并将其发送给组件供应商（EMC Captiva），供应商声称错误是由于“Users”组对该文件没有读取权限造成的。遇到错误的用户恰好是本地管理员，但这不是重点，因为我仍然对更普遍的问题感到好奇。
所以我的问题是，ACL 是否存储在文件中，以便它们在文件的整个生命周期中都遵循该文件，尤其是当许可证文件在我的开发计算机（计算机 1）上生成、存储在 Subversion（计算机 2）中、从源代码管理中签出时由TeamCity（机器3）打包，由InstallShield（机器4）打包成安装程序，最后部署到客户的机器（机器5），由管理员安装？当我在我的开发机器（机器 1）上生成文件，通过组件供应商的支持站点（机器 2）将其上传到组件供应商，然后支持人员将其下载到他们的机器（机器 3）进行检查时，会怎么样？
我不确定这一点（这就是我在这里询问的原因），但我假设每台 Windows 计算机都将 ACL 存储在由 NTFS 管理的某个中央目录/列表/表中，而不是存储在文件中。当原始文件的 ACL 从一台机器复制到另一台机器、存储在 Subversion 中、打包成 MSI 等时，会发生什么情况？有人可以给我指出一些好的参考资料，让我可以阅读这方面的内容吗？
ACL 存储在 NTFS 分区中负责所有后台管理的部分 - MFT（主文件表）。
ACL 不跟随文件，因为它不是文件的一部分（就像文件名一样，它是元数据）。文件可以跨越分区类型边界（NTFS->FAT），但 ACL 不能。
现在如果你move对于一个 NTFS 分区中的文件，您可能会觉得 ACL 实际上跟随该文件。这是因为在移动过程中，实际上仅更改了 MFT 中的文件名。其他一切都保持不变。
如果您复制文件或将其移动到另一个分区或计算机（这实际上是复制+删除操作），复制的文件将默认继承其新容器的权限（准确地说，仅是可继承的权限）。
但是，有些工具能够在复制操作后保留文件的 ACL（只需在复制操作后在目标文件上重新创建它），甚至可以跨分区或计算机边界。 xcopy 可以做到这一点，等等。
但由于 ACL 可以包含“域拥有”的 SID，因此 ACL 条目实际上对于不属于同一域的目标计算机可能没有意义（例如，当将 NTFS 格式的 USB 驱动器带回家时）。在这种情况下，ACL 条目将不起作用。
其他 SID 是“众所周知的”，例如“SYSTEM”SID。这些实际上将跨域边界被识别。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
