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 (functions like fopen
) rather than the native API (functions 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" operations. 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 openening 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 operations 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.
2Renaming a locked file is not a problem on Windows. Deleting usually is, there are few programs that open a file with the FILE_SHARE_DELETE option turned on. – Hans Passant – 2012-02-12T09:01:13.890
You actually didn't delete it, you just unlinked it from the directory it was in. The file still exists, it just may not have any name in the filesystem. (Though it still has a name in the
/proc
filesystem through the program that has it open.) A file can only be truly deleted if there are no references left to it, and this happen automatically. – David Schwartz – 2012-04-12T01:50:38.753