2 ms·
> if the file is open we're kind of assuming we need it, aren't we? What happens if the system tries to read the file on disc and it's been replaced or removed?
by cesarb 7y ago
> if the file is open we're kind of assuming we need it, aren't we? What happens if the system tries to read the file on disc and it's been replaced or removed? Why shouldn't that end in an earth-shattering kaboom?
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.
- SAI_Peregrinus 7y agoOr close the other program. 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.
- cesarb 7y ago> 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.windowsconfidential.aspx http://technet.microsoft.com/en-us/magazine/2009.04.windowsc...
- fredsanford 7y agohttps://docs.microsoft.com/en-us/sysinternals/downloads/handle https://docs.microsoft.com/en-us/sysinternals/downloads/hand...