Jump to content
CCleaner Community Forums


  • Content Count

  • Joined

Posts posted by Augeas

  1. What do you mean by unable to recover?

    Did you find the deleted file?

    Did you attempt to recover it and failed?

    Didi you recover it and the contents were not what you expected?

    How did you delete the file in the first place?

  2. That's right, the O/S and the SSD controller will treat the writing of a new file to 'deleted' pages as an update of the pages.

    By their nature SSDs run with most of their deleted and TRIMed pages unerased, the SSD is shall we say full, even if the O/S only shows live data. Garbage collection is done nowadays i the foreground as it reduces the number of extraneous writes and also lessens the load on portable devices.

    I don't know how the SSD controller can know that pages are no longer used by the O/S's file system. That info is held in the MFT and cluster bit map which the SSD can't read.

  3. A zero fill would use zeroes from the user's point of view, which is greatly abstracted from the actual values written to flash cells.

    If the SSD is quite old (10 years +) then it might not support TRIM, in which case a very infrequent WFS might be beneficial. If nothing is done then there is no way for the SSD controller to know which pages have been deleted by the O/S. When a page deleted by the O/S is subsequently reused the SSD's garbage collector will flag that page as invalid and use a previously erased page. You may have to wait a few micro-seconds in this case.

    This is how USB flash drives work as USB doesn't (or didn't until very recently) support SATA protocol.

  4. I don't use Defraggler so I don't know what options it has but don't you mean CCleaner?

    Whatever s/w it is the process of writing a file and then deleting it is totally different from erasing a NAND flash block. The SSD's grabage collection routines will erase the (invalid) block irrespective of what has been written there previously.

    And don't bother to zero or anthing fill an SSD. Windows will not allow you to access TRIMed data, and the block erasure will remove anything that was written before permanently, so a normal delete will do.

  5. There could be several reasons for this.

    Recuva deep scan runs a normal scan first, so you will see all the deleted file names presented from the MFT. If you have used the 'native' WFS then the file names will be there in their original form. If you have used Drive Wiper then the same number of file names will be there but the names will be in a variable ZZZZ.ZZZ form. In both cases the file data will have gone. You might also have the Show Non-Deleted Files option checked in which case you will see a very large number of live files listed. All these files are 'recoverable', but the wiped ones should return zeroes.

    If the files found are from the deep scan (their names are [000123].ext or similar) then there are some circumstances where a WFS fails to completely wipe the device. Are the deep scan files all relatively small, say 20k or so or less?

    I should check the files with names in  the Header pane of Recuva to see if they contain zeroes. If so all is fine. You could select all deep scan files and run a single pass secure delete. This will clear those files from the device.

  6. Why aren't you trying to scan disk D, which presumably is the 238 gb partition you deleted? Why are you scanning the Recovery partition, which clearly isn't the partition you deleted? Why are you trying to scan a Local Disk, which, whatever it is (someone will tell me) it isn't the deleted partition?

    The three partitions you describe appear to be on Disk 1, but the partition you apparently deleted appears to be on Disk 0. I am too confused to make any sense of it.

  7. It means, in the most basic terms, that what you are trying to play is not a video file. What has been recovered will be faithfully what is on the storage device. What is on the storage device is therefore not a playable video file (you can replace video with any type of file).

    Why is this so? It could be because the file has been overwritten, it's FAT32, it's greater than 4gb, it's an SSD, or it's some kind of coding that needs decoding (I have no idea how Kodak holds its files), or something else I don't know about.

    Can these files be recovered? There's not enough info (there's not any info) to say yes or no, but one could say probably not.

  8. The file count whilst running includes live as well as deleted files. If you are not seeing any deleted files in the l/h pane then possibly there is some selection criteria entered which does not match any file found. It sounds as if you were running a deep scan which I don't think finds RAW files.


    1 hour ago, Hacked Off said:

    Oh dear, still some confusion I see...

    I am not confused.

    1 hour ago, Hacked Off said:

    I understand what you say about the drive waiting to write, and when all the files are deleted, it simply does not write them to the SSD (Actually your explanation is admirably clear, I wish others could explain that bit as well as you did).  What I was thinking about was if CC could issue a "flush to disc" type command, like a removable drive perhaps?  So everything would be written to the device, before anything got deleted, when again the drive would need to be updated.

    Thank you for your compliments, who knows whether CC commits to disk? I would say that it does.

    1 hour ago, Hacked Off said:

    Of course the MFT has no special longevity about it (are you misinterpreting on purpose?).  You were the one saying it would thrash the MFT to write like that, I was simply pointing out that it had to deal with things similar during normal use, so it has to be robust enough.  I never said it was made of special memory or anysuch.

    Misinterpreting on purpose?

    On 29/10/2019 at 10:30, Hacked Off said:

    one has (to) assume that the SSDs were built with many writes to the MFT (and so considerable redundancy) in mind.  Since it does not matter whether the data is CC garbage files, or user files.  The MFT has to be robust enough to cope with user data.

    The phrase 'SSds were built with many writes to the MFT in mind' certainly implies some constructional abilities. It's actually nonsense, as it's NAND flash that holds the MFT (and all other files) and is either robust or not. On reflection I think you may mean robust in a software sense, and that is entirely down to the file system, in this case NTFS. The SSD knows nothing of the MFT and just doesn't come into it.

    1 hour ago, Hacked Off said:

    As for the usable life of the drive...

    I'm not going to get drawn into this discussion, and your strawman arguments about fake chips. SSDs last a long time, and that's that.

    1 hour ago, Hacked Off said:

    Here we go again!  I NEVER SAID financial organizations would use CC, they might use some sort of low-level S/W.

    True, you didn't. But this thread is entitled Using CCleaner on SSDs, and it's in a CC forum on a Piriform Bulletin Board, so one might be forgiven for thinking such.

    1 hour ago, Hacked Off said:

    The overprovisioning memory needs to be reallocated to the main drive as is needed


    I was unsure if any/all might be able to access such areas on SSDs.  Just as in HDDs, it is specialist S?W though and so I was not sure if any of the versions of CC incorporated it.  Maybe I am just seeing ways to make CC work with SSDs, that others have not considered.

    You may not believe what I say, but it is frustrating repeating myself.

    10 hours ago, Augeas said:

    It is not possible to access deleted pages nor the overprovisioning pages on an SSD using non-specialist software running under Windows (and I don't know of any specialist s/w either). If the chips are read in a lab the data is almost certainly encrypted or striped across blocks, and there is no link from one page of a file to another.

    I would suggest that you re-read this thread and perhaps also re-read some of the relevant passages in the previous link (it can be heavy going to tackle all at once). SSDs are far more complex, and different, than many users realise.


  10. It would be better for both brevity and comprehension if if HDDs were left out of this thread, as the title refers to SSDs.

    I said that CC will fill the disk, not write and delete files one by one. However, as described in detail in the link, zero-byte pages are maped to a default zero-byte page, the SSD doesn't write millions of zero-filled pages. Writing random data certainly will fill the addressable pages on the disk, and deleting them will return to the default zero-filled page mapping, just as you were if you hadn't bothered to do all that in the first place.

    The MFT is a file just like all the others. It has no special longevity attributes and is unknown by the SSD controller. If Drive Wiper is used then the MFT is wiped as you require. It is not made larger, or for that matter made smaller, in this process.

    It is not possible to access deleted pages nor the overprovisioning pages on an SSD using non-specialist software running under Windows (and I don't know of any specialist s/w either). If the chips are read in a lab the data is almost certainly encrypted or striped across blocks, and there is no link from one page of a file to another.

    No financial business or organization that might have sensitive data would use a free utility with no authentication or verification for disk sanitisation, and CC, despite what some of its marketing might claim, isn't intended for that purpose.

    The SSD life section is a little tongue in cheek. Of course some electronic devices will fail immediately, some will last seemingly forever. An approximation of the life of NAND flash can be made, and it is a very long time. .I have a 512 mb flash drive dating back to 2006 that has been thrashed unmercifully, and it's still good, if semi-retired now.

  11. To answer your question CC will, if you absoultely force it to, fill the disk with zero-filled files, and then delete them. However CC will warn against this, and indeed it is utterly pointless, achieves nothing, and will hammer the MFT and other system files. It does not even 'fill' the device. It is not, as you imply, 'the ONLY way to "erase" anything from solid state memories'. There is no way, using O/S software. TRIM will do it all for you.

    There's a lot here that is shall we say contentious, but I'm not going to get into a lengthy exposition. If you want you could read through  http://kcall.co.uk/ssd/index.html which goes into considerable detail, even though it is still being updated. You could swap ssd for ntfs in the url for even more bed time reading.

  12. It's been suggested a few times before, and although there is a likelyhood that some file will be modified or unavailable on a restart, that also applies to a certain extent when running Recuva anyway. I doubt if will be implemented, given how many times Recuva has been updated recently (around zero).

    I can't see any real reason why you should not work on your system drive whilst running Recuva. It will slow things down a bit but I'm sure you can live with that.

  • Create New...