When a file is renamed or removed (replace is basically remove followed by rename -- often in one atomic action, of course), the open file handle and the corres

When a file is renamed or removed (replace is basically remove followed by rename -- often in one atomic action, of course), the open file handle and the corresponding inode can be left around and remain usable until the handle is closed. That is orthogonal to whether the filesystem path should be bound to the inode throughout its lifetime. On *ix systems it's not, so for instance a program could easily replace itself with a new version. > 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.