Jump to content
CCleaner Community Forums


  • Content Count

  • Joined

Posts posted by Augeas

  1. I assume you mean the tenor of my post, not the actual meaning. We have no way of knowing from your original post either your skill level or the number of files to be recovered. Company employees do read this forum from time to time, but I wouldn't translate that into action of any kind. I would think that in your case you could look for another application that does recover zero-length files.

  2. 1) Find a live version of one of these files, copy and rename it.

    2) Open Notepad, select Save As, file type Any, save as whatever name you wish.

    I suppose you're going to say you have 20,000 of these files. It may be possible for Recuva to create a new zero-byte file with the same name as the deleted file, but I wouldn't wait for that to happen.

  3. Don't attempt to recover the files at the top of the list starting with $. They are system files, they will exist on the drive you are recovering to, you can't restore them anyway, and even if you could they would be invalid. Some of them are sparse files which means that they theoretically are as large as the device.

  4. Yes, my computer is working fine. No, I don't boot from the USB drive. I don't have a Recuva64.exe either, just Recuva.exe. Perhaps there's some element missing from the Win 10 recovery files that is causing your problem. Recuva for me works just as it does for you. It appears that your problem occurs when you boot from the USB.

  5. A normal and a deep scan will not find the same number of files (although with an SSD it will be close). A normal scan looks at the records in the MFT that are flagged as deleted. These records contain the file's name and cluster addresses, among other things. A deep scan will run a normal scan first, and then look at all the unallocated clusters on the device. When a specific file signature is found at the start of a cluster (and Recuva checks about 20 of the most common) this cluster and those following are presented as a file suitable for recovery. So there will always be more files found in a deep scan, unless the devce is an SSD and TRIM has wiped the clusters.

    There is no difference between saving the results of a scan and leaving Recuva open and acting on the results some time later. I would expect (and hope) that Recuva would check the state of clusters before overwriting them, even if it's only a few seconds after the scan has been run. Recovery is not so much of a problem, as it is not a destructive process and invalid data can be tolerated.

  6. 1) Who knows?

    2) A normal scan will have file names and path if available. A deep scan will have files identified as [000123].jpg etc. These will follow the normal scan results.

  7. 2) A deep scan does not return file names, as it looks directly at the device's clusters which do not contain file name or path information. A deep scan runs a normal scan first so the file names from that will be displayed first.

  8. No. This is for operating systems, or SSDs, that do not have TRIM implemented or enabled. On the assumption that you do, then the answer is still no. The option you want is Optimise, which will run a global TRIM on the SSD. I'd let Windows do it for you.

  9. All files found with a deep scan will be in Excellent condition, as a deep scan looks at unallocated clusters, which by definition can't be in use by any other file.

    A deep scan will only find the first extent of any file, as there is no method at the cluster level of linking extents together. This may result in the file being upopenable.

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

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

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

  13. 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).

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

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

  • Create New...