為什么 Python 文件鎖庫刪除 Windows 上的鎖文件而不是 UNIX？

Question

我正在使用filelock的文件鎖模塊。

• 在 Windows 上，當一個鎖被釋放時，支持它的文件被刪除。

• 在 UNIX 上，即使釋放了鎖，文件系統上仍然存在鎖文件。

操作系統之間的差異是否有原因？ 如果沒有理由讓它有所不同，那么這些行為中哪一個更正確？

Answer 1

專門針對py-filelock

用於刪除filelock上的鎖文件的文件鎖庫； 自benediktschmitt/py-filelock#31 ，此行為已被刪除，它指的是flock()：在沒有競爭條件的情況下刪除鎖定的文件？ - 它討論了本答案后面部分中描述的相同競爭條件。

---

為什么一般做法不同

操作系統語義不同，因此在每種情況下都適用不同的方法。 在 UNIX 中，即使有打開的句柄，您也可以刪除文件，因此不能刪除鎖定文件，否則兩個程序都可能認為它們持有相同的鎖，而實際上它們持有完全不同的 inode 上的鎖，這些 inode 位於不同的點及時，以相同的文件名引用。

相比之下，Windows 上的默認文件系統語義使得在任何程序打開文件時都無法刪除文件（即使 NTFS 強大到足以支持它，但為了向后兼容圍繞 FAT 限制設計的程序，它被人為地阻止了），所以在 Windows 上，刪除鎖文件是安全的：如果刪除成功，則證明沒有人持有鎖（或者甚至正在打開文件以稍后獲取鎖）。

---

一個特定的種族例子

要提供一個示例，說明允許在 UNIX 上取消鏈接打開的文件如何使刪除鎖定文件變得危險，請考慮以下常見競爭條件的圖示：

• 程序 1 創建並打開文件 A1（名稱為“A”），接收附加到該新創建文件的 inode 的文件句柄（object 反映實際文件本身，而不是它附加到的目錄條目）。
• 程序 1 請求對該句柄的排他咨詢鎖定。 沒有其他進程擁有同一個文件的句柄，因此它的鎖請求被授予。
• 程序 2 打開文件 A1，在其上接收第二個文件句柄。
• 程序 2 請求對該句柄的排他咨詢鎖定。 然而，因為程序 A 已經持有一個鎖，所以請求被阻塞——也就是說，程序等待操作系統稍后將控制權交還給它，此時可以授予鎖。
• 程序 1 完成了它需要鎖定的進程。
• 程序 1 使用unlink()系統調用來刪除鎖定文件。 （為了安全起見 UNIX，請忽略此步驟）。 這不會刪除文件本身（“inode”），直到沒有程序打開它，但它會立即從先前包含該文件的目錄中刪除指向該文件的鏈接。
• 程序 1 關閉它對文件的句柄，從而釋放它的鎖。 inode 沒有被刪除，因為 Program 2 仍然持有一個句柄。
• 程序 2 被授予它在刪除發生之前打開的文件句柄（在現在未鏈接的文件 A1 上）上一直在等待的鎖，並且能夠繼續執行。
• 程序 3 創建並打開一個名為“A”的新文件 A2（具有一個新的且不同的 inode）（因為 A1 的 inode 不再鏈接到該名稱，所以該文件可用），並獲得一個文件句柄。
• 程序 3 請求鎖定它擁有的文件句柄。 這是立即授予的，因為 A2 與 A1 是不同的文件，並且仍在運行的程序 2 持有 A1 上的鎖，而不是 A2。 因此，我們最終得到了兩個程序——程序 2 和程序 3——認為它們持有相同的鎖。

因此，上面說明了在 UNIX 上，刪除鎖文件如何允許出現競爭條件，其中一個鎖似乎同時被兩個程序持有。