Eraser does not wipe the recycle bin

[cio328]

I am wiping files with Eraser regularly for a long time now, but few days ago I found that it is not really wiping the recycle bin!

I copied a file to the root of a new empty logical volume in the (magnetic) hard disk, then I deleted it (it went to the recycle bin); next I wiped the recycle bin with Eraser “6.0.8” and it showed as empty.

To verify if the volume had something recoverable I used “Recuva 1.26” (from Piriform) and, to my surprise, the deleted and wiped file was there, intact and ready to be recovered. I indeed recovered it to another volume and compared it to the original from I copied in the first place and both were identical! As it was an executable it was also fully functional!

I faced that problem originally with Eraser “6.0.6” and it does no difference if the file is in a folder, instead the root. Also, I set the “plausible deniability” but it had no effect (no file was copied over the one to wipe).

Eraser “5.86a” (very old indeed) does not present that problem and wipes the recycle bin as expected (file content and file name).

My Windows is XP SP3 (Brazilian Portuguese) and my user is the only one defined at the system (and is also the administrator).

Can that problem be caused by a “Net Framework” restriction? (what can I do to solve it?)

 

[DavidHB]

What may have happened happened is that Recuva found a shadow copy. Those are, as far as I know, not moved to the Recycle Bin when a normal delete is done, and so they are not deleted when the Recycle Bin is erased. This 'safety' feature of the NTFS file system is not good for security! I recommend disabling shadow copies on all drives, only using System Restore (of which shadow copying is a feature) on the system (C drive, and regularly deleting old restore points, so that they get overwritten when you erase free space.

If you had erased the file, rather than moved it to the Recycle Bin, it would not be recoverable. Please test that (and use Recuva to test the erase, which is the best form of test). If that does not work, there should be an entry in the log for the task, showing the error condition.

David

 

[cio328]

Following your recommendation, first of all I verified the system, but the volume where I found the problem did not have shadowing activated already.

Than I made some testing with the volume formatted as NTFS (I see now that I forgot to say that the problem was with FAT32; sorry for the inconvenience). With NTFS Eraser 6.0.8 acts as expected either directly on the file or on the recycle bin.

Going back to FAT32, your recommendation to do a direct erase of a file does the job as expected.

So, the conclusion, for now at least, is to wipe files directly whenever possible and/or use NTFS instead of FAT32 (one more reason to do so) and avoid shadowing also.

Thanks for the quick help!

 

[Joel]

This may be a problem. Eraser should be able to handle FAT32 just fine. How did you format the drive? What is the cluster size of the drive? Did you need to do a deep file system scan for Recuva to find the deleted file?

 

[cio328]

First of all, sorry for the late answer, I was out of town.

I used the regular Windows format to prepare the FAT32 volume for testing (my computer / explorer / right click in the volume / format); that volume has 8,29 GB and I selected FAT32 so the wizard shows only “default allocation size” (is that 8 K clusters?); selecting or not a quick erase does no difference on the results.

Recuva finds the “deleted” file with a normal scan; you don’t need to do a deep scan.

If you test Eraser (copy + delete + wipe the recycle bin) just after the format, you will find that two hidden files (desktop.ini and INFO2), created by Windows to operate the recycle bin, overwrote the object file so all seems to be ok (the object file is unrecoverable). That happens because the object file, in this particular situation, was put in the very beginning of the empty volume and its clusters were marked as free when it was deleted (to the recycle bin) making possible the overwrite. But if you do the testing with the object file put after the “internal” files you can see that it is possible to recover the content.

 

[Joel]

Apologies for the late reply.

I'm trying to reproduce the problem here, but I'm having difficulties getting Windows to create a recycle bin on my drive. Let me try to recreate your scenario before commenting further.