我们的应用程序使用共享目录来存储“签出”，通过我们的应用程序修改的文件，然后“签入”到共享目录，该目录通过SMB访问（环境托管在一组AWS服务器和我们的最终用户通过Citrix访问它。
所有用户都拥有共享目录的读取，写入等权限。
我们最近改变了应用程序的架构。以前，每个用户在共享目录中都有他/她自己的子目录，其中存储了签入/签出文件。
在新架构中，不使用各个子目录，因此用户签入的所有文件都直接存储在共享目录中。然后允许用户签出/签入共享目录中的任何文件。
结帐过程涉及将文件库版本的File.Copy写入用户的本地非共享目录。然后，用户使用我们的应用程序对文件进行更改，然后将其保存在本地，并将File.Copy返回到共享目录中。
除了在新架构中，当用户2尝试签出最初由User1签入的文件时，'checkout'操作失败。尽管我们可以告诉，这是因为例如，当用户1检查到共享目录中的文件时，该文件隐式地接收其特定AD登录的安全条目。用户2的后续File.Copy操作会收到权限错误。如果主机系统的完整管理员删除了用户1的安全条目，则从共享目录到用户2的本地目录的File.Copy工作正常。
请注意，两个用户都被分配到具有读取，写入，修改等的组到共享目录（但不是“完全控制”）。
这似乎似乎就像那种不寻常的情况。我们还没有（还）尝试查看应用程序是否可以通过编程方式删除签入时创建的安全条目 - 即使假设可能，也不必诉诸于此。但是我们没有找到任何有效的安全设置安排。
任何信息或建议都将受到赞赏。
...谢谢
根据要求：
\\citrixfile01\Shares\clients\002\library
ALIGHTENT\002.EightTwoConversion:(I)(OI)(CI)(M)
NT AUTHORITY\LOCAL SERVICE:(I)(OI)(CI)(RX)
S-1-5-21-3973462947-2300097736-545649627-500:(I)(OI)(CI)(F)
ALIGHTENT\citrix:(I)(OI)(CI)(F)
ALIGHTENT\alightcalc:(I)(OI)(CI)(M)
ALIGHTENT\Domain Admins:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
\\citrixfile01\Shares\clients\002\library\AML_AmPac_8.2.amox
ALIGHTENT\002.Admin1:(I)(M)
ALIGHTENT\citrix:(I)(F)
ALIGHTENT\AEAdmin2:(I)(M)
ALIGHTENT\Domain Admins:(I)(F)
BUILTIN\Administrators:(I)(F)
答案 0 :(得分：0)
移动文件时，Windows不会更新ACL以添加或删除继承的权限。这可能是出于向后兼容的原因;在最早版本的Windows NT中，权限模型看起来有些不同。
您的选择是复制文件而不是移动文件，或者在文件移动后显式重置权限。
如果要显式重置权限，可以使用File.SetAccessControl执行此操作。要为新位置应用继承的权限，FileSecurity对象应包含空ACL，AreAccessRulesProtected属性应为false。