Secure delete doesn't seem to work

[hisb]

I've tried to use the feature to securely delete everything found (I opted for the NSA algorithm). After deleting all files (note: some files were not deleted as indicated in the post-delete log), I rescanned the drive hoping to find nothing (except for what was given in the log), and I found what appeared to be everything that was there before, with no noticeable change in the state. I've tried this several times, restarting the program, etc., but nothing seems to work. I've done further testing with select groups and individual files, and it seems I am able to delete some files (e.g. 15 out of ~2000 files, though some of those not deleted were resident in the MFT), but doing this required highlighting for some, checking for others. This seems to be quite glitchy.

 

Also, while it's great to be able to securely delete files, if I can still see the file names, I don't care if NSA or Gutmann says the file cannot be recovered, I don't consider it to be securely deleted.

 

I'm using Vista Ultimate and Recuva file version 1.18.0.344.

[Andavari]

though some of those not deleted were resident in the MFT

That's why they weren't deleted, because they were resident in the Master File Table ("MFT").

[hisb]

That's why they weren't deleted, because they were resident in the Master File Table ("MFT").

 

 

Only some of the files were marked as such, most weren't. However, most of the files marked as deleted and not marked as protected by MFT still remained in "excellent" condition after a rescan. If it were only the files protected by MFT that weren't deleted, I wouldn't have posted this as a bug

[Augeas]

I gather you're saying that all the file names remain, and not that the files can be recovered after secure deletion?

 

Recover does not overwrite the file names or location info in the MFT. Recuva doesn't overwrite anything in the MFT at all. If you want the file names overwritten then there are applications which will do this. This is the nature of Recuva and its big bro CCleaner, they are not disk wipers.

 

How long did your big erase take, by the way?

[hisb]

After doing the first erase of everything (not sure how long this took, my guess is ~10 min.), lots of the files that were in Excellent condition before were still in Excellent condition, i.e. were not over written. If the files had been overwritten, but I could still see the names, this wouldn't be a bug, thus I wouldn't have posted it here. That was an addendum at the bottom of my post for a requested future capability for Recuva (sorry, didn't mean to confuse anyone). The reason for this post is files that should have been overwritten by secure delete (files that weren't resident in the MFT or had other things precluding there being overwritten) were left unaltered after secure delete--they were still green.

 

At a different time, I selected all all Excellent and Poor condition files (i.e. green and orange). Directly after doing this, I was able to select files individually or in small groups and delete them. Again, some I couldn't delete because of being in the MFT, but this is to be expected. Lots of others, though were deleted. These were files that were not deleted before, and were obviously not currently protected by being resident in the MFT.

 

This seemed to happen most of the time when selecting everything (green, orange, red), some of the time when selecting only orange and green files, and only once or twice when selecting a small group of files.

 

How often do files change status of being resident in the MFT? Perhaps I was able to delete the additional files after their status was changed (though I would commonly do the second delete within a minute after the first delete).

[Augeas]

As far as I know the file status is a condition that Recuva attempts to determine, and from my experience is not to be taken as evidence that a file has been securely deleted or not (it's a software guess). File status does seem, in some cases, to change in subsequent runs. I would take evidence of secure deletion as the file header showing zeroes (I do one overwrite). In your case, as you are using multiple overwrites, then the file header is no help: I would take as evidence if the preview shows a picture or if the file can be recovered to its original state. Can you recover any file that you have securely deleted?

 

I have never done a mass file secure delete with Recuva, but 10 mins for 2000 files with multiple overwrite seems far too short, but I may as usual be wrong. You could change your file deletion to one overwrite, do a mass delete, and then quickly scan down the file headers looking for zeroes. It's complicated as you will have to stop for files in the MFT and files that are overwritten by another file, so it isn't an easy job.

 

Just to clarify, although you selected files in excellent/poor status and deleted then successfully, it doesn't necessarily mean that they weren't deleted already. Don't put too much faith in the file status.

 

A file will only change its status of being resident in the MFT if it is edited and increased in length so that it no longer fits in the MFT entry. A deleted file, being uneditable, will remain resident in the MFT until it is overwritten by a new file creation, and the new file may or may not then be resident in the MFT depending on its size.

[hisb]

Augeas, thanks for the useful response!

[Augeas]

Thanks, Hish.