New CCleaner

[Deke40]

I had downloaded the new version of CCleaner and decided to run it with the "Wipe Freespace" checked to see if it had actually been improved.

 

After doing so I used Recuva and the names of the files found had all been changed to a bunch of Zs.

 

Does this mean CCleaner is renaming the files in the MFT now?

 

Here is an image of what Recuva found after running CCleaner with the WF ticked.

 

Also tried to do an overwrite on the files in Recuva that had excellent by them and got this.

[Augeas]

Ah, somebody brave enough to run wfs. For the curious, can you clarify a few points?

 

Did you run wipe free space only, or did you also delete any files?

 

If you deleted files, did you use secure deletion?

 

Are all the files Recuva finds renamed to ZZetc, or just some?

 

Your thumbnail of the Recuva overwrite shows two files overwritten. It is normal for small files in the MFT (less than 1k) not to be overwritten by Recuva, I guess you found two files in the batch you tested that were greater than 1k and thus were overwritten?

 

I assume that the files that Recuva found are of varying sizes, non?

 

Is the Date Last Modified of all the files the same (i.e. when you ran CC), or varying?

[Deke40]

I will try to answer your questions as best I can as I did quite a few things while testing the "Wipe Free Space".

 

Yes I deleted files with CC and used the DOD method along with the "Wipe Free Space" checked.

 

It looked like it renamed all of the ones available although there were a few that came from me using the internet just before I checked the Recuva results.

 

I will have to try an overwrite some of the file again and see the ones it will overwrite and see what they are about.

 

The files Recuva found were all either 592 or 600 bytes, mostly 600.

 

The dates are all the same.

 

I don't check anything under Options\Actions after running WFS it doesn't show very many files as I have not been on the internet much in the interum. But if I check "Show Securly Overwritten Files" it will show all the Z files.

 

Here is an image of one of the Z files properties.

[Deke40]

I was doing some more testing using WFS and decided to do a check on my C drive used and unused space.

 

It had dropped a bunch and as I kept refreshing it it kept dropping. I knew this must be due to the WFS I was doing and had

probably done it when I ran the WFS before but seeing I was only up to 50% on the process of wiping I decided to abort for now.

[Augeas]

Hi Deke,

 

I asked these questions as I was trying to determine what CC does to remove entries from the MFT. It appears that it overwrites them with some form of ZZ file name: whilst it would be better if no other secure deletion takes place so that there's no confusion with the ZZ filenames of that process there's still some info here.

 

I wonder in what order the various processes take place? (I've just thought of this.) If you run secure delete and wfs in one run of CC, does it secure delete the files (renaming them to ZZ), then wipe free space and clear the MFT, including overwriting the entries in the MFT just overwritten in the secure delete process? So that the secure deleted files would not be seen separately in the MFT? That might explain why your files are all 600 bytes long. Ha!

 

Now how does Recuva know that a file has been securely deleted? I must admit I hadn't seen that option. Does this apply to all CC's secureley deleted files or just those that have had an MFT wipe? The option makes no difference on my pc. I don't think there are any flags in the file header that say securely deleted, so filename is just about all there is to go on. The ZZ format is variable, or appears to be. Can you confirm that Deke? So does Recuva look for files held in the MFT (i.e less than 1k) and contents binary zero? Or some other method?

[Augeas]

More tests. I copied a 15k file into my crap folder and secureley deleted it. It showed in Recuva, I set the option not to show securely deleted files, and it didn't show.

 

I then copied the same file into my crap folder, and renamed it to ZZZZZZ.ZZZ and ran CC on Normal Deletion. I scanned with Recuva and the file showed with the option ticked, and disappeared with the option unticked. So it appears that the filename is the selection criterion for secure deletion. It also shows that if some fool names his files ZZZZZZ.ZZZ they will be classed as securely deleted, even though they aren't. (My jpeg file was fully visible in the preview panel.)

[Deke40]

Did you notice the big drop off on your Free Space as I did while the wipe was taking place.

 

I guess I will run another later and see how far down it actually goes. I kind of panicked on the last one when it got down

below 85GBs.

 

It also had opened a file of about 34MB on my C drive but it was gone when I shut CC down and looked for it again.

[Augeas]

I don't actually use wfs, only on flash drives to test it, and they're FAT. Sometimes an interrupted wfs leaves large files in the c dir, these can be safely deleted (and can be seen using Recuva, if you haven't wiped the MFT!).

 

I wonder what method CC uses to overwrite the MFT entries. The usual way is to fill up the drive with large files (as wfs does) then allocate new small files under 1k to fill up the MFT, then delete the lot. Maybe that's the only way for a Windows application. But if you did that then there would be at least one entry in the MFT that would represent a very large file.

 

I guess you could obtain the number of free entries in the MFT and then allocate the same number (or a few more to be sure) of small files. In that way you could do a MFT wipe without wiping all the free space. Nobody appears to do that though. Well, you can do that on a DIY basis if you want. It would be a good tweak for CC, as many users want to wipe the MFT without the pain of wiping free space.

[Augeas]

Another spanner in the works. Previously if I ticked or unticked Show Securely Deleted Files there was no difference to the number of files displayed (i.e there were no files recognised as securely deleted). This afternoon sys restore dumped a few hundred deleted files as it does every week or so. Now if I untick Show Securely Deleted Files there are 22 files hidden, and if I tick it all are shown. None of the files are of the familiar zz format. Fifty-eight have z in the name, four have zz, and only two have zzz (or more) in the filename. So zz isn't the way of identifying a securely deleted file. Surely Piriform works in mysterious ways.

[Deke40]

Another spanner in the works. Previously if I ticked or unticked Show Securely Deleted Files there was no difference to the number of files displayed (i.e there were no files recognised as securely deleted). This afternoon sys restore dumped a few hundred deleted files as it does every week or so. Now if I untick Show Securely Deleted Files there are 22 files hidden, and if I tick it all are shown. None of the files are of the familiar zz format. Fifty-eight have z in the name, four have zz, and only two have zzz (or more) in the filename. So zz isn't they way of identifying a securely deleted file. Surely Piriform works in mysterious ways.

 

 

My old brain is about on overload already so I am going to dwell on it for awhile.

 

Merry Christmas to you over the pond as your are 6 hours closer to it than we are.

[Augeas]

And the same to you Deke, alcohol has started to flow here...

 

I've identified my 22 securely deleted files as those with no filename, path as c:\?\ and zero length. I don't know where they came from, presumably from the sys restore file dump. My ZZZZ.ZZ file still counts as a securely deleted file as well. I think I need more alcohol.