Jump to content
CCleaner Community Forums


  • Content Count

  • Joined

Posts posted by Augeas

  1. Those ignored files are files that have not been deleted, live files from the install and whatever else has taken place.

    A deep scan with scan for non-deleted files doesn't make sense. Addresses for non-deleted files are held in the MFT, and a deep scan doesn't look at the MFT.

    If you have run a format which zeroes the free space then all this is of no avail.

  2. I would advise against it, as with that amount of data you will almost certainly overwrite what you are trying to recover. You need a separate drive with al least as much free space as the source drive.

    Have you tried a scan with Scan for Non-Deleted Files checked?  If you did a quick format this may be of more help than a deep scn, which does not return file names or directory structure, and only recoveres the first extent of any file.

  3. I don't know why I typed c:\r, I should have said make the destination folder d:\r to emphasise that the recovery is to a different drive from the source drive.

    The recovered files are sent to a folder elsewhere, which makes the path name longer by adding the recovery folder name to the file names. The idea is to keep the recovery folder name as short as possible.

    To have 4,000+ names that are at, or close to, the file name length limit is rather unusual.

  4. I wish Excellent would be replaced with something else more descriptive, such as Not Overwritten, or Maybe, or perhaps Perhaps? It means that the file is not at this moment overwritten by another live file, not that the data is in any way valid or even useful.

    In Recuva Advanced mode have a look at the Header. This might tell you whether the data is in OO format (I don't know what that is, Google it). If it isn't then what you're recovering isn't an OO document. The data might have been overwritten by another file which has itself been deleted, or you're looking in the wrong place (cluster addresses invalid).

  5. Try to recover it to a folder in the root directory which has a name of one letter only, i.e. d:\x

    This will only add one letter to the file's full path name and with a bit of luck it can be recovered, then renamed.

  6. In future runs forget three passes, one will do. Shooting a horse three times doesn't make it three times deader.

    Did you use WFS from Options/Settings or Drive Wiper?

    Slack space does not contain deleted file data, it contains what was there in the unused space if the file didn't completely fill the last allocated cluster. A deleted file cannot be reconstructed from slack space, by definition.

    CC WSF does not care about slack space anyway, or even files, as it operates at cluster level. There are some circumstances where WFS will leave some clusters untouched, and some small deleted files will remain unwiped, but I don't know if this applies in your case.

  7. Assuming that it's NTFS then files 4gb and larger have their cluster addresses and some other fields in the MFT set to zero on deletion by MTFS. The file is effectively unrecoverable. Files less than 4gb can also have cluster addresses set to zero if they are, or were, heavily fragmented.

  8. It's common in new installation to see very many deleted files from the install. Non-deleted files will have Non-Deleted (or whatever the description is) as their status. To stop showing non-deleted files uncheck the box in Advanced mode/Options/Actions. Free and Pro versions act the same.

  9. It appears that the deleted file is called sandvich.png somewhere in c:\users. The overwriting file is also called sandvich.png in c:\users. If you follow the path of the overwriting file you will find a live copy of sandvich.png. As the deleted file and the overwriting file are both the same image then when you recover the deleted file you will get the live file's contents. This has caused the confusion. I don't know if you want to get rid of sandvich, but if you do then delete the live copy. You will then be able to overwrite your deleted file.

    This may have been caused by sandvich being deleted and then recreated more or less immediately afterwards. The new allocation has used a different record in the Master File Table to write the file name etc, but the same clusters have been used to hold the new file. Thus the live file and the deleted file entries in the MFT point to the same clusters, and co-incidentally it is the same image as before.

  10. The entry for the deleted file in the Master File Table contains the addresses of the clusters it used. If these clusters have been reused then another live file is using them - they have been overwritten. The cluster addresses in both the deleted file and the live file point to the same clusters  If you recover an overwritten file you will be recovering (copying) what's in the live file. the data from the deleted file has gone forever. You cannot secure overwrite the deleted file's clusters because they are being used by the live file. Recuva is working fine, this is how NTFS works.

  11. Recuva is working fine. Overwritten by another file means that the deleted file's clusters have been reused by another live file. You can 'recover' the original file as a recovery is simply copying what's in the file's clusters. What you will get however is the data from the overwriting file, the original data has gone forever. You cannot overwrite an overwritten file as you would be overwriting the data from the new file, which is not what you want to do.

  • Create New...