At least 20% of my grief while using Windows stems from not being able to remove or replace open files.
This happens when I start a script or a LaTex file etc by right-clicking in an empty folder to create a new text file, then changing the name of the file and its extension. It's an empty file with a .txt extension, yet windows has to ask me whether I'm sure I really want to perform this desperate and dangerous act that might cause some programs to not work any more.
Isn't the problem actually not being able to effectively close it to then replace it?
- update immediately(ish) seen by other users of the file (e.g. database); the default UNIX semantics, even for executables
- update seen by other users at the next point they open the file (what you want for update-without reboot, can be achieved on UNIX because deleted inodes hang around)
- it's completely impossible for other users to write, rename etc the file (Windows default)
1. It’s not built into Windows, requires separate download;
2. Searching is hit or miss.
File and it's directory entry are two separate things. So you can remove and replace open file, but the old handle will still point to the old file - it just won't be open-able using the original filename. Once all the processes will close the handle to the old file, and no directory entry points to it, it will be removed from the file system.
Many programs do the "write to temp file and rename on top of old file" trick, which is almost-atomic, and you can have multiple programs doing that to the same file at the same time without noticing.
(If you're on NFS writing to a deleted inode may do something different and probably broken)
I think part of my problem is I'm visualizing this as a shared file being updated by users, and not, say, system updates. System updates make sense - we can assume only the system will be modifying them, and it'll be relatively low touch, but I keep visualizing a shared text document.
Usually these multiple processes have some agreed way to take their turn on writing; or they use library like sqlite (or berkeley db in the past), that library brings that mutually-agreed locking mechanism with it.
The only thing that does work with shared writing is logiles with O_APPEND, where multiple processes can safely add to the end of a file.
(For historical examples of this, have a look at mbox locking versus maildir; the "mbox" format is basically keeping all your email as a huge text file, and locking protocols have developed around that so multiple mail clients can coexists without wrecking it)
> Isn't the problem actually not being able to effectively close it to then replace it?
Not sure what this is supposed to mean. The program that's keeping the file open could effectively close it. The problem is other programs can't, plus it's hard to hunt down the process that's hanging on to a file.
On Unix, the directory entry does not point directly to the file contents. It points to an "inode", which contains the file metadata (owner, permissions, timestamps) and points to the file contents. When you remove a file, you are actually removing the directory entry; the inode will only be removed when nothing else points to or is using it. An open file keeps a reference to the inode, so the system can still read the file just fine, even if the directory entry has been removed.
Some other operating systems, like MS-DOS and Windows 9x, do not have that distinction. On them, the directory entry has the same role as the inode on Unix-style systems, which means it cannot be removed while the file is in use. The Windows NT line, when using NTFS, does have something similar to the directory entry and inode split from Unix, but it still denies removing or replacing in-use files for compatibility with Windows 9x.
> Isn't the problem actually not being able to effectively close it to then replace it?
The problem is when another software (for instance, a file indexer or an antivirus) has the file open. You cannot force the other program to release its grip on the file; the workaround is to set the "pending delete" flag for the file and schedule a reboot.
Also, "You cannot force the other program to release its grip on the file; the workaround is to set the "pending delete" flag for the file and schedule a reboot. " is somewhat wrong. You can close the handle the other program holds on the file, it just might crash that other program.
It might do more than just crash that other program. Some other component within that program might open a new file (or even things which are not really files), and happen to get the same handle you had just closed (once the handle is closed, its number can be reused). Then the original component finishes what it was doing and closes the handle; the second component thinks it's still open. A third component opens a new file, and again gets the same handle. Now the second component tries to write to the handle (it might be something like a log file), and the write goes to the wrong place.
Force closing a handle on a different process leads to undefined behavior, and as always with undefined behavior, anything can happen.
Raymond Chen also has an article about this: http://technet.microsoft.com/en-us/magazine/2009.04.windowsc...
Examples of insane behavior of UNIX's lack of locking:
- A process can get its file corrupted because flock() is cooperative, so there isn't any enforcement that even if file locking is used, it actually works. Hence the dance with temporary lockfiles as workaround.
- A process can happily store important information into a file just to have it deleted under its feet after the usage count of the inode goes to zero, and good luck bringing the data back to life without forensics tools.
Quite sane indeed.
Many people also swear that only bad programmers write C programs with memory corruption bugs.
Files are just memory in a different storage device.
In theory only bad programmers write code with bugs related to Windows file locking, and yet... well just check the OP I guess