eraser does not delete directories

aK68KEvE

New Member
hi

when you right click on a directory and chose erase all the files in the directory will be deleted.
the top directory looks to be renamed and ereaser does not delete it because it still looks for the original name. :cry:

please advice
beside this - this piece of software is great

rgds
 

Joel

Active Member
Go to the task log and see what error Eraser had erasing the directory. It should be written clearly there. If the error there was that sharing violations occurred you can delete the folder yourself (manually)
 

aK68KEvE

New Member
yes, it's

Code:
Donnerstag, xx. Februar 2010 xx:xx:xx	Error	The process cannot access the file 'C:\Y`!SW\' because it is being used by another process.
"Y`!SW" is the renamed directory by eraser.

Can you explain?

Cheers
 

CorrsFan

New Member
I have the same problem. Only seemed to start after installing version 6.0.6 (was running a much older version prior). Running on Windows 7 Home Premium, 64-bit. It simply fails to remove ANY top-level folder, but it does remove the files inside the folder. The top-level folder is just renamed to a random sequence of characters, and I have to manually delete it.

The error in the log is the same: "cannot access file...because it is being used by another process".

I do NOT have Windows Indexing Services enabled on the drives these errors typically occur on, as that was my first thought, but I'm still inclined to believe that it's some interaction problem with Explorer.
 

DavidHB

Active Member
I shall be interested to see what Joel says on this; he hasn't posted for a few days. But my couple of months with Windows 7 have convinced me that it is even more prone to leave inaccessible files lying around than Vista. The really annoying bit is that, most of the time, users have no idea what those files contain ...

That said, if your folders contain zero bytes, they are more of an annoyance than a risk. See if you can access and delete them from an elevated command prompt, which sometimes works.

David
 

Joel

Active Member
I've also seen that Explorer likes locking directories for no good reason either, which I can't seem to understand why.
 

eraseruser0

New Member
I'm running Eraser 6.0.6.1376 on Vista SP2 and I get this quite a bit. Eraser seems to have problems only with the LAST directory it is dealing with, which has somehow gotten locked by Explorer and Eraser can therefore not delete it. The dir gets renamed, but not deleted.

So, for example, I have a dir called DIR containing 26 directories and files in them. The files are deleted fine. The 26 directories are deleted fine. The DIR, however, is renamed to ZXZXZX (random name) but Eraser then reports back that it could not delete that directory because it was locked, or not available, or some such. (When I next get the error I'll come back and report more fully.)

On a slightly related note, I've also seen Eraser appear to give a directory a name containing strange characters which it can then not delete (or so the error msg appears to indicate). I've only gotten this error twice though, and don't remember the circumstances, so I can't quite nail down the issue yet. If I see the error again I'll report it more thoroughly, with the dir name.
 

Joel

Active Member
There is one bug fixed in trunk and 6.0 that handles errors because of randomly-named directories conflicted with reserved names, that should account for more than half the errors you get. The fix will be found in 6.0.7, due to be out later this week.
 

eraseruser0

New Member
6.07 seems to no longer have this problem EXCEPT when I use the "replace file with another file for plausible deniability" (or whatever that option is called), in which case it seems to happen both for files and for directories. That is, after the erasing and the renaming, the file (or directory) that is itself left over does not then get deleted.

I'm using the 6.07 stable release (.1853 I think?) on Windows Vista SP2.
 

Joel

Active Member
Thanks for reporting the bug! The bug was fixed in 6.2 a while back, but I didn't backport the change to 6.0 thinking that it wasn't affected. The fix has been committed in r2014
 
Top