5 ms·
Windows has the reverse problem, where you are blocked to delete an in-use file, but it's buggy as hell and very opaque as to what is holding that file.
by Pxtl 5y ago
Windows has the reverse problem, where you are blocked to delete an in-use file, but it's buggy as hell and very opaque as to what is holding that file.
- zvrba 5y agoThe windows feature is not buggy, the process that created the file potentially is as the creating process chooses the sharing mode. Except for executable images (EXE/DLL): they're always locked on the filesystem as long as any running program is referencing the image. That's by design: designers didn't want "invisibly" used space on disk. For what happens when you do that on Linux: the file entry gets deleted, but disk space doesn't get deallocated until the last program using the file has exited. If you replace the file, the program will still be referencing the old file (now unreferencable by any name/path, except possibly through /proc/../fd).
- Pxtl 5y agoI've dealt with far too many cases of crashed programs retaining their locks on files to call it anything but buggy. And Windows offers no UI for finding out which process is holding the file handle.
- zvrba 5y agoI think your diagnosis is wrong. When the program exits, in whatever way, all resources/locks/etc are cleaned up. (Hey, the OS is also nice enough to tell waiters about abandonend mutexes.) There's no built-in GUI, but there's Process Explorer and other sysinternals utilities that you can use to find out what is keeping the file open.
- layer8 5y agoWindows comes with Resource Monitor which can be used for that purpose: https://superuser.com/a/643312/62 https://superuser.com/a/643312/62