Secure deletion only on certain drives?

CCleaner for Windows
1

I've recently upgraded my Windows drive to an SSD. I understand that all of the secure deletion methods used by CCleaner are not only useless on an SSD, but with the way the drives work, would increase write amplification quite a bit. That being said, I still have 3 mechanical drives in my system which are used for storage and I would like to be able to use secure deletion with them even if I'm not using it on my C drive. Is there a way to configure CCleaner so that with one cleaning pass it will use secure file deletion techniques on my mechanical drives, but normal file deletion on my SSD, thus leaving it to delete files in its own way and not increasing write amplification? Or am I stuck with only normal file deletion for all drives to keep my SSD in good shape?

Thanks.

2

It - secure deletion on an SSD - might not be all bad. Now I don't have an SSD and I'm not the world's SSD controller expert, but here goes.....

I'm assuming that the SSD is formatted to NTFS and that you have TRIM available and enabled.

On a normal delete (shift/del) the TRIM command will remove the file's pages from the LBA mapping tables and consign them to the invalid page pool, ready to be erased by the garbage collector and assigned to the available page pool. A request to read the deleted pages will cause a default page of zeroes to be returned. This is effectively a secure delete. You can test this by shift/del'ing a file and then look for it with Recuva. The file name will remain in the MFT so you will find the deleted file, but the data (as shown in Recuva's header display), should show zeroes. Try this and then post whether it's true.

A CC secure file deletion will overwrite the file with zeroes (one pass please!) and then delete the file. However an SSD page write requires a new page to be written and the old page discarded, hence the additional and unwanted page writes. But all is not quite what it seems.

To write a page of zeroes the SSD would have to retrieve an empty page set to the default values of '1', and then change every bit from '1' to '0'. The SSD controller is crafty enough to detect what's happening, and instead of going though this laborious and pointless process, just unmaps the target page and sets the LBA mapping for the page to the default page of zeroes, similar to the normal delete/TRIM process.

CC finishes its processing by deleting the page of zeroes, which effectively does nothing to the SSD's pages but flags the file entry in the MFT as deleted. If the result from the normal delete test above is zeroes, then I can't see a way of testing the secure delete process, as the results are the same.

As I have said previously, there was considerable interest a few years ago when CC wipe free space was found to speed up SSD processing. I don't think anyone sussed out what was happening, but I believe that the wfs (a mass secure delete) by writing pages of zeroes was effectively trimming the SSD pages by forcing the deleted pages to be unmapped, paving the way for them to be erased and made available. This was before the days of TRIM.

If you want to do something mildly interesting, have a look at unused pages on an SSD or a flash drive with a hex editor (WinHex or something similar). The default state of an empty NAND flash page is ones, yet you will see screens full of zeroes. That's because you're being presented with the default page of zeroes by the flash controller. Funnily enough, storing a page of zeroes is an impossibility on a SSD or flash device.

3

It - secure deletion on an SSD - might not be all bad. Now I don't have an SSD and I'm not the world's SSD controller expert, but here goes.....

I'm assuming that the SSD is formatted to NTFS and that you have TRIM available and enabled.

On a normal delete (shift/del) the TRIM command will remove the file's pages from the LBA mapping tables and consign them to the invalid page pool, ready to be erased by the garbage collector and assigned to the available page pool. A request to read the deleted pages will cause a default page of zeroes to be returned. This is effectively a secure delete. You can test this by shift/del'ing a file and then look for it with Recuva. The file name will remain in the MFT so you will find the deleted file, but the data (as shown in Recuva's header display), should show zeroes. Try this and then post whether it's true.

A CC secure file deletion will overwrite the file with zeroes (one pass please!) and then delete the file. However an SSD page write requires a new page to be written and the old page discarded, hence the additional and unwanted page writes. But all is not quite what it seems.

To write a page of zeroes the SSD would have to retrieve an empty page set to the default values of '1', and then change every bit from '1' to '0'. The SSD controller is crafty enough to detect what's happening, and instead of going though this laborious and pointless process, just unmaps the target page and sets the LBA mapping for the page to the default page of zeroes, similar to the normal delete/TRIM process.

CC finishes its processing by deleting the page of zeroes, which effectively does nothing to the SSD's pages but flags the file entry in the MFT as deleted. If the result from the normal delete test above is zeroes, then I can't see a way of testing the secure delete process, as the results are the same.

As I have said previously, there was considerable interest a few years ago when CC wipe free space was found to speed up SSD processing. I don't think anyone sussed out what was happening, but I believe that the wfs (a mass secure delete) by writing pages of zeroes was effectively trimming the SSD pages by forcing the deleted pages to be unmapped, paving the way for them to be erased and made available. This was before the days of TRIM.

If you want to do something mildly interesting, have a look at unused pages on an SSD or a flash drive with a hex editor (WinHex or something similar). The default state of an empty NAND flash page is ones, yet you will see screens full of zeroes. That's because you're being presented with the default page of zeroes by the flash controller. Funnily enough, storing a page of zeroes is an impossibility on a SSD or flash device.

So shift-deleting some test files from the SSD and then attempting to recover them did result in a found file name, but only zero's returned in the header, further borne out by the fact that any file recovered by Recuva in this way produced a file of the correct size, name, and extension, but when viewed with a hex editor only presented zero's. I've also had a look with the hex editor at the SSD as you suggested and found nothing but zero's in unused portions of the drive.

That all being said, I'm not so sure the SSD controller is "crafty" enough to intercede before a write operation like that. Right now I'm trying to think up a way to verify it one way or another... I'm a little brain dead after work, but I'm thinking if I write a large file to the drive (file > 1GB) while monitoring the SMART value for total LBA's written before and after and then deleting the file with CCleaner using secure overwrite and checking the SMART values again. If you're correct, the only increase in LBA's should come from the initial write of the file, but if the controller isn't as smart as you say it is, then the LBA's should jump by a similar amount both after the initial write and after the secure delete.

4

Ok, so I've run my test and the results were as I suspected: When using CCleaner to securely delete files from an SSD the controller does not intervene to in the processes, but rather simply executed the requested overwrite.

Pre-Write LBA's: 1056305627

Post-Write LBA's: 1059437490

Post Secure Delete LBA's: 1064912549

That being said, I think I know why the results were different than you expected.

As you said, when you shift-delete a file, the TRIM command does remove the mapping from the file system tables and then the result is that even though the file name and size still exist in the MFT, the actual data contained within the file is lost within the drive. This, however, is not what I would consider to be a "normal" delete, but rather a "manual" delete. A "normal" deletion within Windows is when you delete a file to the recycle bin, from which it is then "emptied", which would be the equivalent of a manual delete of the contents of the recycle bin. The problem here is that CCleaner counts on the second method to be used to even bother with trying to clean a file. The file must still exist in the recycle bin (or other defined location e.g. Temp) for CCleaner to even detect that it must be overwritten. As a result, if the secure delete is attempted on a file, that by definition would mean that the file had not yet been deleted from the file system map, so, even if the controller was programmed to ignore unnecessary writes like you described, the fact that the file still exists for CCleaner to want to securely erase it means that the controller would likely see the attempt to overwrite the file as a valid change to the file in question, thus reading the file into memory, releasing the original pages, and writing all of the new info (a bunch of zeroes) to the new pages before then receiving the delete command from CCleaner and releasing the new pages.

Anyway, this all brings me right back to the original question of whether or not there is a way to set up CCleaner to use secure delete my mechanical drives and normal delete on my SSD so that all can be dealt with in the same cleaning operation?

5

No, it doesn't address your original question. I don't have an answer for that, perhaps there's some fancy winapp2 or ccleaner.ini trick that will enable this, but it needs an expert on these to comment. You could have two CC portable setups, one cleaning the SSD without secure delete, and the other with all file selections off except your includes for the non-system drives, with secure delete. OK, two runs, but safe, and do you clean the stuff from your non-system drives as frequently as the SSD?

Anyway, my point was that perhaps CC's secure delete isn't so bad after all on an SSD. And it's an interesting technical diversion, maybe.

Your lba numbers aren't as easily interpreted as all that. In fact we don't know if the lba write number includes those unmapping actions. Samsung says that the Total LBAs Written 'Represents the total size of all LBAs (Logical Block Address) required for all of the write requests sent to the SSD from the OS', whatever that means. Also a file delete will update the entries in the directory and file records in the MFT, the MFT bitmap, the cluster bitmap, the transaction journal, and stuff I can't think of at the moment. Does it also include TRIM lba changes?

Personally I think that SSD controllers are far more intelligent than at first might seem, and are easily capable of detecting a zero-filled page. A better test would be to check the lba before and after count during a shift/del delete, and a before/after count on the same files during a secure delete, taking care to eliminate all extraneous activities.

6

As for how much I clean each drive, I would say the volume of files removed from the mechanical drives is definitely more as they are my dead storage / working file drives. In the course of a week I probably write and delete at least 10GB of files from them. The files I clean from my SSD, on the other hand, are mostly temporary files and the like, so there are probably more in quantity, but far less in size. As a result, I'm often emptying the trash to clean up unused space on my mechanical drives more than I'm using CCleaner to clean temp files off my C drive, so I guess if I had to choose one that was more important, it would be having secure delete for the mechanical drives.

You mentioned the winapp2 and ccleaner.ini, and I'm hoping someone will pipe up about the possibility of setting those up to do it in one pass, but it occurs to me that I could create a ccleaner.ini file with the settings to clear out my mechanical drives and then another for the SSD and then swap them out based on which drives I'm cleaning at the moment. That being said, I'm curious just how I would set up CCleaner to use secure deletion while at the same time completely excluding it from attempting to clean anything off of my SSD?

I would probably take the Samsung description of the Total LBA Written value at face value, meaning the total LBAs written to the drive. I am pretty sure it includes those written through the garbage collection process as if it really only included the total size of files sent to it by the OS, it would be a fairly useless statistic to include as it would potentially leave out a large amount of writes undertaken by the controller itself and thus return an increasingly inaccurate value as time goes on. That being said, I will try the test again as you described it when I get home from work. I will delete the file with shift-delete and the monitor LBAs written over time (the garbage collection process on my drive can take up to two hours) and then the same deletion with secure delete to see if the former method indicates a similar size in writes after GC as the secure delete.

This brings up another question though, namely what is considered a write. If the default blank page is all ones, and then a write must be executed to change some of those ones to zeroes to populate the page, then the act of reverting a page back to ones may not be an actual write. In this case, GC may only write the changes to the file system tables and then only perform a reset on the actual pages in memory. I guess the test may indicate the answer to this, as a change to the file system would only be a small amount of writes, no matter the file size.

7

I was hoping that someone on this forum would chime in here to give some instructions about setup, at least so far as to ensure that I don't execute any sort of secure delete on my SSD, but it seems that no one who knows this has seen this thread. Where would I go to find this more technical information?

8

I'm curious just how I would set up CCleaner to use secure deletion while at the same time completely excluding it from attempting to clean anything off of my SSD?

As the SSD is your system drive, nothing will be cleaned form your three hdds unless there are Include statements in CC, yes?

So one folder containing a portable version of CC could have normal deletion checked with no Includes (SSD), and another folder containing a portable version of CC could have secure deletion enabled with nothing checked except Includes (hdd). Portables have their own version of the cleaner.ini file, so all runs are independent.

You could set up a small batch file to run both versions of CC at the same time, or just run each one separately according to your requirements.

This is a bit basic, but then so am I. If anyone has a more sophisticated method then please chip in.

9

As the SSD is your system drive, nothing will be cleaned form your three hdds unless there are Include statements in CC, yes?

This isn't quite true. In windows, each internal drive has its own Recycle bin (external drives simply execute a manual delete), so when you delete a file from that drive using a normal delete, the file system moves its mapping to the local recycle bin to await final deletion. When you give the command to empty the recycle bin, Windows goes through each drive's recycle bin and deletes the file mappings so that without a scan of the drive by something like Recuva, its essentially gone. As I've established earlier in this thread, for CCleaner secure delete to work, the file(s) in question need to still exist and be marked for deletion. This presents a problem for the method you've described above, as it would require one instance of CCleaner to exclude the recycle bins of all mechanical drives to ensure that they are not emptied using the simple delete method, while then the other instance would exclude the recycle bin of the SSD to ensure it's not emptied using secure delete. Because Windows doesn't differentiate between the different drives' recycle bins, I'm not sure it's possible to do this.

I guess one inelegant way around this would be to create a folder on each mechanical drive to set as an include and then move files there to have CCleaner secure delete them. In this way they wouldn't go into the recycle bin on their local drive and I wouldn't have to figure out a way to exclude specific recycle bins from the execution of the SSD instance of CCleaner. The problem though is that moving files to a specific folder on each drive when I want to delete them would get tedious fairly quickly compared to selecting and hitting delete.

EDIT: I ran a quick test by deleting some files from a mechanical drive to the recycle bin, then running CCleaner with that drive excluded completely (D:\*.*). Considering this exclusion would have included the D drive recycle bin path, if it would be possible to restrict CCleaner from emptying a specific bin, this would be a likely way to do it. Unfortunately, it did not work and those files were indeed removed despite the exclusion.

10

Sometimes to get exclusions to work you have to manually edit the settings, so an exclusion of D: would look like one of these (assuming you're using ccleaner.ini for the settings, and I don't know if it works on whole drives like this):

Exclude1=PATH|D:\|
Exclude1=PATH|D:\|*.*
11

Ah yes, the recycler messes up the whole plot. As I very rarely use the recycler (I'm a shift/del addict) I had overlooked that aspect. more brain cells needed.

12

Sometimes to get exclusions to work you have to manually edit the settings, so an exclusion of D: would look like one of these (assuming you're using ccleaner.ini for the settings, and I don't know if it works on whole drives like this):

Exclude1=PATH|D:\|
Exclude1=PATH|D:\|*.*

I'll give this a try tomorrow when I have a little free time to see if it affects the outcome at all

Ah yes, the recycler messes up the whole plot. As I very rarely use the recycler (I'm a shift/del addict) I had overlooked that aspect. more brain cells needed.

You do know you can set Windows to simply delete in that method by default, right? You don't always have to shift delete if you never plan on using the recycle bin...