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用户那里了解更多答案吗？在这里查看完整的讨论主题。