我的 IT 部门犯了一个错误，并且每一个文件系统上的文件root:OurGroup。然后他们的自动备份（即.snapshop）系统创建了一个快照，所以我们不再有以前的权限的参考。
我正在尝试与他们合作制作一个脚本，该脚本将设置 set-uid 位并由 root 拥有，用户可以根据需要调用它来将文件/目录重新分配给他们。
我预料他们不会想要一个可以随意 chown 任何东西的脚本，但可能愿意创建一个新用户，将所有内容 chown 给该用户，然后让用户可以调用该脚本，如果该文件属于另一个用户，则该脚本将拥有 chown 文件。
但是，为了避免竞争条件，我想找到一种方法，当且仅当文件归此用户所有时才更改所有者。但是这里有一个竞争条件：如果我在两个单独的调用中执行此操作，并且两个用户同时对一个文件运行此脚本，则可能会导致冲突。相反，我想在一次调用中“如果所有者是用户，则更改所有者”，而不是“如果所有者是用户”，然后“更改所有者”
是否存在用于文件所有权的原子比较和交换原语？
答案1
但是，为了避免竞争条件，我想找到一种方法，当且仅当文件归此用户所有时才更改所有者。但是这里有一个竞争条件：如果我在两个单独的调用中执行此操作，并且两个用户同时对一个文件运行此脚本，则可能会导致冲突。相反，我想在一次调用中“如果所有者是用户，则更改所有者”，而不是“如果所有者是用户”，然后“更改所有者”
您似乎暗示，一旦文件的所有权从 更改为root:OurGroup更理智的内容（例如user1:department-name 第二个用户），就不应该能够再次将所有权从 更改user1:department-name为user2:some-team。
但这并不是真正的问题……
问题不在于两个用户同时运行脚本或chown接连或同时执行命令，问题要困难得多：
当多个用户声称拥有同一文件或目录的所有权时，如何解决冲突？
想象一下，运行你的脚本的第一个用户只是选择每个文件和目录......
当所有文件从root:OurGroupUID:GID 转换为时，您的问题是否得到解决user1:department-name，然后所有权是否已正确恢复？并且是否应该拒绝
仅希望拥有所有权的用户 2 的后续运行？<path>/Department-Name/User1's files/*
正如@Lacek提到的那样 - 最好的选择是使用较旧的备份作为当前文件系统中仍然存在的任何文件的所有权模板，并且只关注备份中不存在的新创建的文件。 （第一级方法赋予这些文件与封闭目录相同的所有者）。
以及命令chmod都chown支持--reference标志。您可以从备份位置指向现有文件，并chown使用该参考文件/目录的所有者和组，而不必直接指定 OWNER:GROUP 值，即类似以下内容：
cd /old-backup-of-nfs-share/
find . -exec chmod -v --reference='{}' /current-nfs-mount/'{}' \;
答案2
在 shell 中没有这样的东西，但是你可以用它模拟它flock（参见此 Stackoverflow 条目）
然而，正如 Sven 指出的那样，您必须使用sudochowning 文件，因为脚本会忽略 setuid 位。
另外，恢复较早的备份并检查其中的权限可能是一个更好的主意。它可能会涵盖您要处理的大多数文件，并且这似乎是一种比让用户猜测更准确的恢复所有权的方法。