确保尝试删除文件时未更改该文件
在 POSIX 环境中，我想从磁盘中删除文件，但在删除之前计算其校验和，以确保它没有更改。锁定足够了吗？我应该打开它，取消链接，计算校验和，然后关闭它（以便操作系统可以删除其索引节点）？有什么方法可以确保没有其他进程在该文件上有打开的文件描述符？
为了提供一些背景信息，该代码执行跨主机的文件同步，如果远程主机删除了文件但该文件正在本地更改，则可能会丢失数据。
In a POSIX environment, I want to remove a file from disk, but calculate its checksum before removing it, to make sure it was not changed. Is locking enough? Should I open it, unlink, calculate checksum, and then close it (so the OS can remove its inode)? Is there any way to ensure no other process has an open file descriptor on the file?
To give a bit of context, the code performs synchronization of files across hosts, and there's an opportunity for data loss if a remote host removes a file but the file is being changed locally.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您的 open、unlink、checksum、close 提议将无法按原样工作，因为如果校验和不匹配，您将被卡住（没有 POSIX 可移植的方法来创建到文件描述符给定的文件的链接）。更好的变体是重命名、校验和、取消链接、关闭，如果校验和不匹配，它可以让您撤消重命名或重做副本。您仍然需要考虑如果第三个程序同时重新创建了该文件您想要做什么。
POSIX 仅提供协作锁。如果您可以控制可能修改文件的程序，请确保它们使用锁；如果这不是一个选择，那么您将陷入无锁状态。
没有可移植的方法来查看哪些进程（甚至是否）打开了文件。在大多数 Unix 系统上，
lsof会向您显示，但这不是通用的、不健壮的（程序可以在lsof完成查找后立即打开文件）并且不完整（如果文件通过 NFS 导出，则可能无法了解活动客户端）。查看其他同步程序正在执行的操作可能会对您有所帮助，例如 rsync 和 unison。
Your proposal of open,unlink,checksum,close won't work as is, because you'll be stuck if the checksum doesn't match (there is no POSIX-portable way of creating a link to a file given by a file descriptor). A better variant is rename,checksum,unlink,close, which lets you undo the rename or redo the copy if the checksum doesn't match. You'll still need to think of what you want to do if a third program has recreated the file in the meantime.
POSIX offers only cooperative locks. If you have control over the programs that may modify the file, make sure they use locks; if that's not an option, you're stuck without locks.
There is no portable way to see what (or even whether) processes have opened a file. On most Unix systems,
lsofwill show you, but this is not universal, not robust (a program could open the files just afterlsofhas finished looking), and incomplete (if the files are exported over NFS, there may be no way to know about active clients).You may benefit from looking at what other synchronization programs are doing, such as rsync and unison.