Aviator81

I'll give this a try tomorrow when I have a little free time to see if it affects the outcome at all 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...

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.

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?

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.

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?

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.

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.

Up until today, Speccy reported my memory speed as 2400Mhz (what it's set to in XMP), now suddenly its reporting that as 1197Mhz. I've done some googling already and found quite a few replies to similar questions stating that this is because it's dual channel memory, but if this were the case, why would Speccy have reported the BIOS set 2400MHz and then change without warning? I'll admit that it's been about a month since the last time I used the program, but I didn't install any updates until after I noticed this issue. I'm wondering now if this is an issue with the program, or if I may be having issues with my memory. Any input would be greatly appreciated. Thanks.