Files still recoverable despite several "secure delete" operations

Often times, after I've run ccleaner's Drive Wiper, I'll run a scan in Recuva to see if there are any files which might not have gotten overwritten. (Sometimes I'll work or surf while it's running, so I know it can't catch newly updated files.) Usually it's only a few files, so I'll just use Recuva's "secure delete". Today there were just some picture files in Chrome's cache (they had viewable "previews"). Their initial state was "very poor". I ran "secure delete" (Gutman) and they changd to "unrecoverable". But I could still see the preview. I repeated the "secure delete" operation, and still the preview was there, but in "unrecoverable" status. Just to see what I would come up with, I decided to recover a few of them. And despite them being listed as unrecoverable, I was able to recover them. All I had to do was add the jpg extension to them and the recovered files looked just as good as the preview in Recuva.

Another test I tried was, after I performed the "secure delete" and the file state changed to "unrecoverable", I ran the scan again, and they had returned to the "very poor" condition. Long story short, even after performing a "secure delete" several times on the same file(s), I was still able to recover them and open them with no problems and no loss of quality.

(Hmmmm...noticed a typo after I hit "submit" but couldn't find option to edit post title - even using "full editor".)

post-73060-0-95617600-1433177693_thumb.jpg

post-73060-0-45424700-1433177708_thumb.jpg

Title fixed (only something a moderator can do)

There is currently a few of these posts covering the 'problem' of Recuva doing its job versus CCleaner 'wiper' not being up to the job.

What would be nice is if you could use some other drive wipe software, then use Recuva & see how that changes things.

If Recuva still gets those files back then Recuva is doing a fantastic job.

If Recuva can't, then CC is doing a lousy job.

From a quick look at your pics it appears that some of the data clusters of this file (000025) are overwritten by another live file. The status on an initial scan is therefore Very Poor. Running a secure overwrite will overwrite the remaining clusters, and Recuva will change the status to Unrecoverable, as it knows that the remaining clusters have been overwritten. When a new scan is run Recuva does not know that a previous run has overwritten the valid clusters and the status returns to Very Poor.

When the clusters of a deleted file have been overwritten by a live file and the deleted file recovered, you are in effect recovering the live file, which can be opened quite happily. This is all normal processing for any recovery software.

Title fixed (only something a moderator can do)

Thank ye kindly, Nergal. Much appreciated.

From a quick look at your pics it appears that some of the data clusters of this file (000025) are overwritten by another live file. The status on an initial scan is therefore Very Poor. Running a secure overwrite will overwrite the remaining clusters, and Recuva will change the status to Unrecoverable, as it knows that the remaining clusters have been overwritten. When a new scan is run Recuva does not know that a previous run has overwritten the valid clusters and the status returns to Very Poor.

When the clusters of a deleted file have been overwritten by a live file and the deleted file recovered, you are in effect recovering the live file, which can be opened quite happily. This is all normal processing for any recovery software.

Just to make sure I'm understanding correctly, are you saying that the Preview displayed wasn't of the f_000025 file, but of whichever file was listded in the "comments" section (and also the "info" tab)? Is that also the file you refer when you say "live file"?

Thanks,

Well, it's only a theory (although quite common in practice), so yes.

The entry in the MFT for the deleted file contains addresses of the data clusters. These data clusters have been marked as free when the file was deleted. Another file - the file named in the comments section - has used these clusters. If you recover the deleted file you are copying the data clusters that used to hold the deleted file, but now - in part - hold the live file. So you are looking at, and recovering, the live file.

You'd need to switch to Advanced mode and look at the file info to see what clusters have been overwritten. The first clusters in the list (cluster 0 onwards) should be overwritten otherwise the recovered file wouldn't open.

Edit... Phew - just as I pressed post the electricity failed, probably due to this tornado we're having in the UK. Freezing to death last night, blown away today, I blame, oh I dunno, anything.

Well, it's only a theory (although quite common in practice), so yes.The entry in the MFT for the deleted file contains addresses of the data clusters. These data clusters have been marked as free when the file was deleted. Another file - the file named in the comments section - has used these clusters. If you recover the deleted file you are copying the data clusters that used to hold the deleted file, but now - in part - hold the live file. So you are looking at, and recovering, the live file.You'd need to switch to Advanced mode and look at the file info to see what clusters have been overwritten. The first clusters in the list (cluster 0 onwards) should be overwritten otherwise the recovered file wouldn't open.Edit... Phew - just as I pressed post the electricity failed, probably due to this tornado we're having in the UK. Freezing to death last night, blown away today, I blame, oh I dunno, anything.
OK, now I get. it makes sense now. Thanks very much for taking the time to explain it (a couple of times, even). :-)

There is currently a few of these posts covering the 'problem' of Recuva doing its job versus CCleaner 'wiper' not being up to the job.What would be nice is if you could use some other drive wipe software, then use Recuva & see how that changes things.If Recuva still gets those files back then Recuva is doing a fantastic job.If Recuva can't, then CC is doing a lousy job.
OK, now that my issue has been resolved, the least I can do is "pay my bill." I also have [another product] on my system. (I get the license thru giveawayoftheday). But I should clarify my comments to make sure we're on the same page. My issue wasn't with ccleaner not wiping. Basically, instead of me launching the wipe process and leaving it to run uninterrupted, I often work or surf at the same time, so when it's completed,I know I've probbably been writing to places it was trying to write to. So, what I do is, run Recuva and there's might be a few hundred files it locates. (On the other hand, when I do let ccleaner run uninterrupted, usually overnight, when it's completed, Reuva usually doesn't find anything other than the zz files.) And I would Recuva's "Secure overwrite" to take care of those. And now after Agueas' explanation, (I was seeing the preview of the live file, assuming that was the "deleted" file), I'd say my issue is resolved.However, if you have a scenario you'd like me test using [other product] and Recuva to maybe help resolve some other claims, I'm willing. I've only used their "Disk Eraser" (drive wipe) process a couple of times, but it always took too long, so I swithced back to using ccleaner's. But their "System Cleaner" seems to catch more system & log files than cc, so I use theirs.Anyway, feel free to let me know.And thanks again to all who replied. M

Sorry for the edit of your post. unknown to you, we aren't allowed to let competition be named in the forum (innocent mistake, you were kinda asked to by another member).

I think @Augeas has explained nicely a theoretical solution to this and the other 'why is Recuva finding files after a wipe' concerns.

Thanks for that, it's always a relief when my theories aren't immediately rubbished. This thread, by the way (and this is an observation not an admonishment), shows how difficult it is sometimes to diagnose a problem at a distance, when a relevant piece of information - 'instead of me launching the wipe process and leaving it to run uninterrupted, I often work or surf at the same time' - is not introduced until after we've spent a considerable time trying to sort it out.

Thanks for that, it's always a relief when my theories aren't immediately rubbished. This thread, by the way (and this is an observation not an admonishment), shows how difficult it is sometimes to diagnose a problem at a distance, when a relevant piece of information - 'instead of me launching the wipe process and leaving it to run uninterrupted, I often work or surf at the same time' - is not introduced until after we've spent a considerable time trying to sort it out.

Sorry, Augeas. I thought you had understood that from my original post with this:

"(Sometimes I'll work or surf while it's running, so I know it can't catch newly updated files.) Usually it's only a few files, so I'll just use Recuva's "secure delete".

The main reason I clarified was because my original concern was I thoiught I was still recovering files after several attempts at Recuva's "secure delete" on a few select files,whereas it looked like mta was referrring to people who hadn't attempted what I had done.

Sorry about that.

Sorry for the edit of your post. unknown to you, we aren't allowed to let competition be named in the forum (innocent mistake, you were kinda asked to by another member).

No apologies needed. And thank you.

you were kinda asked to by another member

Off with their head! :P

That's OK, probably me forgetting what you originally said. All is forgiven if you rode in, or even attended, the Manx Grand Prix in 1972.

That's OK, probably me forgetting what you originally said. All is forgiven if you rode in, or even attended, the Manx Grand Prix in 1972.

As a matter of fact...

post-73060-0-55556700-1433664522_thumb.jpg

Anyway, thanks again for all your help (and patience).