Why can't I change the name of a file that's being read on Windows as I can do on Linux/Mac?

Question

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.

Answer 1

Whenever you open or execute a file in Windows, Windows locks the file in place (this is a simplification, but usually true.) A file which is locked by a process cannot be deleted until that process releases it. This is why whenever Windows has to update itself you need a reboot for it to take effect.

On the other hand, Unix-like operating systems like Linux and Mac OS X don't lock the file but rather the underlying disk sectors. This may seem a trivial differentiation but it means that the file's record in the filesystem table of contents can be deleted without disturbing any program that already has the file open. So you can delete a file while it is still executing or otherwise in use and it will continue to exist on disk as long as some process has an open handle for it even though its entry in the file table is gone.

Answer 2

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.

Answer 3

This is a very interesting question and it has made me think about a viable answer. I hope others can provide backup here.

I use both Windows and Linux and noticed this as well. I am also a user of vim. Vim will read a text file into a 'buffer', or the RAM, and then not touch the actual file until you save. Linux might be performing this sort of action in general with all files.

Take your video for example, it reads the video, all of it if possible, into RAM, and then you have a copy of the video that is easily accessible, seekable, jumpable. If the file is too big then you might experience problems because Linux might not read the whole video, maybe just a large chunk. When your player gets to the end of the buffered video it'll try to read the file again. If you've deleted the video then that sucks for you.

Windows is a much 'safer' OS in some cases because it won't let you do that. It might buffer the files the same way that Linux does but also adds file locking to prevent you, or other programs, from altering files you are working on or viewing. This helps keep the file intact and keeps you or other programs from overwriting each other's changes.