I deleted a file from Explorer, but it came back when I refreshed, and I get Access Denied if I try to delete it again

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.)