Jump to content
CCleaner Community Forums


  • Content Count

  • Joined

Everything posted by Augeas

  1. If what you want to do is to restore a damaged file then neither CCleaner nor Recuva is suitable. CC removes temporary files and Recuva copies deleted files, neither will bring a damaged live file back to undamaged condition.
  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
  3. You could have typed 'seagate ST1000lm035' into Google instead of waiting for one of us to do it. It is SATA and is an HDD. Defraggler identifying it as an SSD is incorrect.
  4. Perhaps you're on an SSD. Perhaps you have something in the file/path box that doesn't match any files found.
  5. 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 t
  6. Yes, but why do you think that this file is corrupt? I think you need someone who is more au fait with repairing Win system files than I am.
  7. What exactly do you mean? Is the file live or deleted? What makes you think it doesn't exist?
  8. Lucien (if you're still with us), files that are marked as overwritten are overwritten by a live file, there is no concept of being overwritten by a deleted file. So your hideous images must be live, somewhere on your disk. Recuva will tell you where they are in the Info pane.
  9. 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.
  10. 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.
  11. 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 e
  12. No. It's an SSD and on formatting a global TRIM is run resulting in a squeky clean storage device.
  13. 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?
  14. I'm not sure what you mean there. If you plough through http://kcall.co.uk/ssd/index.html it will give me time to go to bed.
  15. 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
  16. 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 US
  17. 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.
  18. 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
  19. Yes, I would recover files in a bunch at a time, step by step is the way. The original file names will be preserved if they are shown in the scan. For files found with a deep scan, those with a file name of [001234].jpg for instance, file names can't be retrieved.
  20. Unfortunately not. You will have to start again.
  21. 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.
  22. Recuva works by copying data to another drive, creating new files. I know of no practical way of identifying the original dates of the files.
  23. I believe Win 10 disables System Restore by default.
  24. No, the red dotted files have their data overwritten by another file, so they are not recoverable. (Actually they are, but you will be recovering the data from the overwriting file which presumably you don't want.)
  • Create New...