When you’re using Linux and OS X, the operating system won’t stop you from deleting a file currently in use yet on Windows you’ll be expressly barred from doing so. What gives? Why can you edit and delete in-use files on Unix-derived systems but not Windows?

今天的問答環節是由SuperUser提供的，SuperUser是Stack Exchange的一個分支，是一個由社群驅動的問答網站分組。

問題

超級使用者閱讀器侏儒想知道為什麼Linux和Windows對在用檔案的處理方式不同：

One of the things that has puzzled me ever since I started using Linux is the fact that it allows you to change the name of a file or even delete it while it is being read. An example is how I accidentally tried to delete a video while it was playing. I succeeded, and was surprised as I learnt that you can change just about anything in a file without caring if it’s being used at the moment or not.

那麼，在幕後發生了什麼，阻止他像在Linux中那樣在Windows中肆意刪除東西呢？

答案

超級使用者的貢獻者為我們提供了一些資訊侏儒. 他寫道：

每當您在Windows中開啟或執行一個檔案時，Windows都會將該檔案鎖定在適當的位置（這是一種簡化，但通常是正確的）。被程序鎖定的檔案在該程序釋放之前不能被刪除。這就是為什麼每當Windows必須自我更新時，需要重新啟動才能生效。

另一方面，類似Unix的作業系統（如Linux和macosx）不會鎖定檔案，而是鎖定底層磁碟扇區。這似乎是一個微不足道的區別，但這意味著可以刪除檔案系統目錄中的檔案記錄，而不會干擾任何已開啟該檔案的程式。因此，您可以在檔案仍在執行或以其他方式使用時刪除該檔案，並且只要某個程序對其具有開啟的控制代碼（即使其在檔案表中的條目已消失），該檔案仍將繼續存在於磁碟上。

David Schwartz進一步闡述了這一觀點，並強調了理想情況下的情況以及實際情況：

Windows defaults to automatic, mandatory file locking. UNIXes default to manual, cooperative file locking. In both cases, the defaults can be overriden, but in both cases they usually aren’t.

A lot of old Windows code uses the C/C++ API (functi*** like fopen) rather than the native API (functi*** like CreateFile). The C/C++ API gives you no way to specify how mandatory locking will work, so you get the defaults. The default “share mode” tends to prohibit “conflicting” operati***. If you open a file for writing, writes are assumed to conflict, even if you never actually write to the file. Ditto for renames.

And, here’s where it gets worse. Other than opening for read or write, the C/C++ API provides no way to specify what you intend to do with the file. So the API has to assume you are going to perform any legal operation. Since the locking is mandatory, an open that allows a conflicting operation will be refused, even if the code never intended to perform the conflicting operation but was just opening the file for another purpose.

So if code uses the C/C++ API, or uses the native API without specifically thinking about these issues, they will wind up preventing the maximum set of possible operati*** for every file they open and being unable to open a file unless every possible operation they could perform on it once opened is unconflicted.

In my opinion, the Windows method would work much better than the UNIX method if every program chose its share modes and open modes wisely and sanely handled failure cases. The UNIX method, however, works better if code doesn’t bother to think about these issues. Unfortunately, the basic C/C++ API doesn’t map well onto the Windows file API in a way that handles share modes and conflicting opens well. So the net result is a bit messy.

這就是問題所在：兩種不同的檔案處理方**產生兩種不同的結果。

有什麼要補充的解釋嗎？在評論中發出聲音。想從其他精通技術的Stack Exchange使用者那裡瞭解更多答案嗎？在這裡檢視完整的討論主題。