Open File Deletion
Discussions center on OS behaviors for deleting or modifying files still open via file descriptors, contrasting Unix-like systems (unlink keeps file until all FDs closed) with Windows (prevents deletion), including issues with sharing FDs, locking, and portability.
Activity Over Time
Top Contributors
Keywords
Sample Comments
Shouldn't this be possible by looking inside of /proc/ if the file's still open?
Including if the file is already being used by another process, what could go wrong.
There is no guarantee of that if one does retain the open file descriptor.
Wouldn't fopen and friends also have issues when locking isn't working properly?
Even if you have opened it, you have no guarantee that the file descriptor has not been closed since. Yes, that would be stupid of the user of the library, but many security lapses happens because people makes stupid assumptions. Code to close all file descriptors on fork for example is fairly common, so you can not safely assume that the file descriptor remains valid.
It's the right thing to give an error that some process has the file open but never tell you which process that is?
What do they do about open file descriptors?
How would you pass an open file by value? What happens when one copy tries to close the file while another still has it open?
This is essentially the same as using unlink on Linux, because this also keeps the file around until it is open.
Off topic: what type of error can occur when closing a file? Is it somehow possible that the kernel denies your request, and forces your handle to stay open?