[英]Why does the Python filelock library delete lockfiles on Windows but not UNIX?
I'm using the filelock
module for Python .我正在使用
filelock
的文件锁模块。
On Windows, when a lock is released, the file that's backing it is deleted.在 Windows 上,当一个锁被释放时,支持它的文件被删除。
On UNIX, lock files still exist on the filesystem even after the locks are released.在 UNIX 上,即使释放了锁,文件系统上仍然存在锁文件。
Is there a reason this is different between operating systems?操作系统之间的差异是否有原因? If there isn't a reason for it to differ, which of these behaviors is more correct?
如果没有理由让它有所不同,那么这些行为中哪一个更正确?
py-filelock
py-filelock
The filelock
library used to delete lockfiles on UNIX;用于删除
filelock
上的锁文件的文件锁库; this behavior was removed as of benediktschmitt/py-filelock#31
, which refers to flock(): removing locked file without race condition?自
benediktschmitt/py-filelock#31
,此行为已被删除,它指的是flock():在没有竞争条件的情况下删除锁定的文件? -- which discusses the same race condition described in a later section of this answer. - 它讨论了本答案后面部分中描述的相同竞争条件。
The operating-system semantics are different, so different approaches are appropriate in each case.操作系统语义不同,因此在每种情况下都适用不同的方法。 In UNIX, you can delete a file even while there's an open handle, so lockfiles must not be deleted or else two programs can both think they hold the same lock, when in fact they hold locks on completely different inodes which were, at different points in time, referenced under the same filename.
在 UNIX 中,即使有打开的句柄,您也可以删除文件,因此不能删除锁定文件,否则两个程序都可能认为它们持有相同的锁,而实际上它们持有完全不同的 inode 上的锁,这些 inode 位于不同的点及时,以相同的文件名引用。
By contrast, default filesystem semantics on Windows make it impossible to delete a file while any program has it open (even though NTFS is powerful enough to support it, it's artificially prevented for backwards compatibility with programs designed around FAT limitations), so on Windows, it's safe to delete a lockfile: If the deletion goes through, that proves that nobody held the lock (or was even in the process of opening the file to later grab a lock on it).相比之下,Windows 上的默认文件系统语义使得在任何程序打开文件时都无法删除文件(即使 NTFS 强大到足以支持它,但为了向后兼容围绕 FAT 限制设计的程序,它被人为地阻止了),所以在 Windows 上,删除锁文件是安全的:如果删除成功,则证明没有人持有锁(或者甚至正在打开文件以稍后获取锁)。
To provide an example of how allowing open files to be unlinked on UNIX makes deleting lockfiles dangerous, consider the following illustration of a common race condition:要提供一个示例,说明允许在 UNIX 上取消链接打开的文件如何使删除锁定文件变得危险,请考虑以下常见竞争条件的图示:
unlink()
syscall to delete the lockfile.unlink()
系统调用来删除锁定文件。 (To be safe on UNIX, just leave this step out). Consequently, the above illustrates how on UNIX , deleting lockfiles allows race conditions wherein a lock can appear to be held by two programs at once.因此,上面说明了在 UNIX 上,删除锁文件如何允许出现竞争条件,其中一个锁似乎同时被两个程序持有。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.