Overwrites but can't delete


New Member
Yes, I'm running elevated, just as the FAQ says - shut down the instance, checked to ensure the process wasn't running, re-ran as admin, got the UAC prompt. Eraser 6 is happy to overwrite each file but leaves a zero-byte randomly renamed entry in the folder and a "files' permissions prevent access to this file" log entry.

Maybe I shouldn't worry, as I can delete each of these files. But it does leave the folder names intact.

Any suggestions?
I assume you are using Windows 7; which version of Eraser are you using?

How did you initiate the task: context menu, drag and drop or in the schedule?

Is the zero byte file visible in Explorer, or did you find it in some other way? And were you trying to erase the folders whose names were left intact.

The purpose of these questions is to see if I can reproduce your results.

I suspect that Eraser may have had difficulty with one file (perhaps one that by accident has come to be owned by the hidden System User, whose files cannot even be accessed when you run elevated). In the past, I have found that these odd file system related problems can often be worked around by moving the file/folder in question to the Recycle Bin and erasing that. If the problem is the Recycle Bin folder itself (as it can be), the inelegant but usually effective solution is to run Explorer elevated, delete the hidden system Recycled folder on the target drive and then (if you need to) do a free space erase.

It does seem to be a permissions problem; NTFS does allow files to be modified (which is what step 1 of erasing would do) but not deleted (which is what step 2 of erasing would do). In those situations you'll have an error like yours.

The easier approach is to do as David says. The more complex approach, if you know what you are doing, is to reset the file's permissions to give your user account full control (or just grant modify/deletion rights)

The NTFS permissions system is *very* complicated. I do not know of any other OS with the same level of permissions and configurability, which is powerful but also makes it a maintenance/sysadmin nightmare.
Unless you really know what you are doing (or have no other option), I'd recommend against manual changes in permissions. I have done it (and still do it occasionally), but my experience confirms what Joel says, in that it is all too easy not to get what you wand and/or to produce results you did not intends.