A customer reported that if they go into Explorer and delete a file, the file disappears from the Explorer window, but if they refresh the window, the file comes back. If they try to delete the file again, they get an Access Denied error.
What’s going on?
The Windows model for file deletion is that deleting a file doesn’t take effect until all open handles to the file are closed. When you delete the file from Explorer, the file operation engine performs a DeleteÂFile to delete the file, and the call says “Yup, the file is deleted. Everything is awesome.” But secretly, everything isn’t awesome yet.
The file operation engine is told that the DeleteÂFile was successful, so it sends out a notification that says, “In case anybody cares, I just deleted a file!” The Explorer window receives this notification and removes the file from the view.
When you refresh the window, the Explorer window goes back and enumerates the contents of the directory, and hey look, the file is still there. So it shows back up.
If you try to delete the file a second time, the call to DeleteÂFile fails because the file has already been logically deleted. The file system is just waiting for everybody who was using the file to be done with it.
The customer’s investigation was that the file is indeed still open. The had an application running that had the file on a work list, and to ensure that the work could be completed, the application keeps a handle open to those files until the work is completed (or canceled).
The customer wanted to know if there was a way to make the file really be deleted when the user deletes it, so it doesn’t show up in the Explorer view, because their employees’ workflow is to delete the file when they’ve finished with it, and having the file linger in the view makes it hard to keep track of what is left to be done.
Well, the work isn’t actually done, because it’s still sitting on the application’s work list. They can adjust their workflow so they delete the file when the application completes the work item. Or find a way to delete the work item from the application’s work list. Or they could talk to the application vendor and ask if there’s an option to disable the “keep an open handle to the file” feature, even though it means that when the application goes to work on the file, the file may not be there any more. (Or it might be a different file entirely, just with a coincidentally identical name.)
It seems like the real issue here is showing "Access Denied" when trying to delete a file that has already been logically deleted. I don't know if that's the actual error code returned by the filesystem or if Explorer is (mis)interpreting it, but if Explorer showed a message saying "This file is pending deletion and will be removed once all references to it are closed or the system is restarted." Or throw something...
The Linux/UNIX way is slightly better.
They remove the directory entry, but keep the allocation on the file system. When there are zero "hard links" the file is then reclaimed.
There are strange situations, where a file can be deleted, and another one can be written with the same name. Now there could be two applications open files with the same name but different contents. A very good way to introduce bugs if files are used as...
Is there also a Nuclear Option somewhere? Something like “Close all open handles to this file whether their applications want it or not, BWAHAHAHAHAHA”?
In early 2020 a Visual Studio bug drove me to build said nuclear option. It works reliably unless somebody has a mapped section on the file.
And no, it doesn't cause the cascading file handle problem because I did it right. With the target process paused, I closed the handle and opened a handle to NUL in the same slot. This takes a truly annoying amount of code because Win32 doesn't have int 21h function 46h....
Force-closing handles is usually a bad idea.
(I love that after almost 20 (!) years of blogging and magazine articles, at this point you can find a post by Raymond on almost any topic. Maybe it needs a cool Internet-rule name, like the “Raymond Completeness Conjecture”.)
I’ve never seen such behavior from File Explorer. It either deletes the file or generates an error message. Sometimes, it even finds out which app is locking the file, preventing its deletion.
I think I read that this behaviour can be changed by FILE_DISPOSITION_POSIX_SEMANTICS?
If it can I want to know exactly how to do it.
I took to renaming the file before deleting it in application code because this misfeature stinks to high heaven.
Now someone's going to come along and say some application might be depending on the old behavior. Well let them have their old behavior until they're fed up with it. My code doesn't need this, nor do the files that my code manipulate because again they're...
You could additionally schedule the file for deletion on reboot.
Unfortunately that flag needs to be set by the program or driver doing the delete – I saw this in the file system implementation of the MSVC STL:
Link to Source.
Doesn’t work. The Windows Executable Loader is still the offender.