Jump to content
CCleaner Community Forums


  • Content Count

  • Joined

Posts posted by Augeas

  1. What you are seeing is the file entry in the MFT. The file's data will have been overwritten, If you look in the Info pane in Recuva you will see that the header is all zeroes.

    When you run a secure delete in Recuva the file status will turn to red, as Recuva knows that it has been overwritten in that session. When you restart Recuva the status will be back to green, as Recuva has no way of knowing that you overwrote the file on the last run, and a file of all zeroes is, or can be, a valid file.

  2. The concept of secure deletion cannot exist on NAND flash. Secure deletion is a process of overwriting a file's clusters (or pages in SSD terms) and then deleting it. A page on an SSD can't be overwritten, a new page is always used.

    A normal deletion with TRIM will flag the page as invalid. It cannot be accessed by Windows or any software generally available. A secure deletion, if attempted, will flag the page as invalid, create a new page of zeroes (the overwrite) and then flag that page as invalid (the deletion).

    So there is no difference between normal and secure deletion, except that secure deletion wastes time and effort and SSD life. Don't use it.

    If you don't believe me (and you don't have to) run Recuva against your SSD. It will find many deleted file names, as they are held in the MFT, but all the headers will contain zeroes. This is TRIM doing it's work for you.

    • Thanks 1

  3. Now you're saying something completely different. First you said that a system file was corrupted. What makes you think this? What other people have described this 'scenario'? Now you say that the MFT isn't 'intact'. Of course Recuva assumes an intact MFT, as does Windows and the user, it's the most critical file you will ever find, and the most securely protected. Nobody on this forum knows how Recuva's inner workings actually work, we can only second guess from our own experience.

    Your understanding of CCleaner is incorrect. CC requests NTFS to delete a file, which it does by flagging the entry in the MFT as deleted. The entry is still there. The 'full edition' acts in exactly the same way. It's NTFS that deletes files, not Recuva. Entries in the MFT are never physically deleted, but flagged as deleted and subseqently reused.

    I still don't really know what you're trying to achieve.

  4. There's no auto stop and restart facility with Recuva.

    If you are running a recovery (which I understand you are) and not an analyse, you could theoretically stop the recovery, identify what the last file recovered was, and then check the files from that point onwards and run a recovery. But if you are dealing with thousands of files this is likely to be quite a headache to attempt.

    Your recovery appears to be grindingly slow, and Recuva appears to be doing nothing in the Task Manager snapshot.


  5. Simple question first - are you trying to save the files to the same drive?

    I've only seen this message (can't find file) on files greater than 4 gb, which I can only see one in your list. Apart from that I can't see why you are getting that message for all the files.

    A file with a header of zeroes is not a valid file, unless it's a text file of zeroes, so it is not a suitable candidate for recovery.

  6. That link is hardly relevant as it discusses correcting an undeleted file, not recovering a deleted file. Recuva does not alter one bit of the data it recovers, or more correctly copies.

    Carmella, no software can guarantee to recover a deleted file, it depends entirely on the subsequent activity on the disk. If it is an SSD then forget any hopes of recovery. If it did not appear in the list of found files then it's likely that the entry in the MFT has been overwritten. You could try running a deep scan and looking for .doc or .docx files with a size close to the deleted file. If no file exists with the approx size then it is possible that the file is fragmented. If so it is not possible to recover fragmented files from a deep scan with Recuva.

    Windows updates deleting user files seems very peculiar to me, perhaps someone with more knowledge on this can comment.

  7. 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?

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  • Create New...