> "But no new file handles can be opened. One by one as processes close file handles, they can no longer open new ones, until the last user has released the last handle."
Or, you know... the computer has to restart itself for some reason before the file was fully deleted, and you get a fragmented disk.
If I'm asking to delete a file, I want the file deleted. I want to know whether the deletion succeeded or not. I don't want it to secretly hide in a purgatory somewhere.
If the kernel gets to shut doen gracefully, then there is no problem at all. The file handles are closed when the processed are killed and the filesystem is unmounted in a consistent state.
If the kernel does not get to shut down gracefully (crash or power loss) the filesystem is left no more or less inconsistent than by any other kind of ongoing activity (nothing worse about a pending free-these-blocks vs a pending anything else), and is cleaned up by fsck or by the journal if there is one. Either way the file is finished being deleted on reboot because no processes have open handles and the kenel and the fs know that those blocks are deleted. The last on-disk state of those inodes was that the blocks are not used by any normal file. They are marked pending to be freed but hadn't been freed yet, but now during the mounting process at boot there are no processes that own them, so they are freed. It's no different than the normal process if there were no power loss.
There is no such problem.
As for "some kind of purgatory" and "I want to know it's done now" these imply ignorance of what a multi process operating system is, what it needs to do, the basic job of a kernel, etc. Not just in linux but nt and any other os that allows multiple concurrent processes.
It's the primary job of the kernel to manage exactly such coordination between a process, another process, and the hardware. Slightly virtualizing things like ram and disk is the very job the kernel is there to do, and what makes multiple concurrent processes even posible.
When you delete a file from a process and get your return from that syscall, it IS "really done right now" as far as that process and all other processes are concerned, and "from your point of view" is as "real" as anything ever gets for any process. The fact that some other process can continue reading and writing to a file handle you no longer care about is none of your business any more, and your intent that the file no longer exist in the filesystem so that it could be created again without conflict, or so that it no longer appears in listings, all does happen as you requested, and immediately.
If you had a file named foo, and you needed to delete that because you need to create a directory named foo, you can do that. It happens exactly as you need, even though some other process now has a file handle open to some invisible file that used to be named foo. That other file handle is just not your problem any more. It's as if the other process simply opened a new temp file in some other firectory that has nothing to do with you.
Or, you know... the computer has to restart itself for some reason before the file was fully deleted, and you get a fragmented disk.
If I'm asking to delete a file, I want the file deleted. I want to know whether the deletion succeeded or not. I don't want it to secretly hide in a purgatory somewhere.
Is this the year of the Linux desktop already?