Jump to content
CCleaner Community Forums


  • Content Count

  • Joined

Posts posted by Augeas

  1. Do you mean Yes it's FAT? It's almost impossible to guess what has happened. Are the files showing as deleted or live?

  2. The file you attached appears to be a string of various chunks of data. The first chunk is a png, so if you rename the file it will display as some sort of weather icon. There's a lot of other stuff following that which might or might not be valid. I guess that in some way the cluster addresses are corrupt, so Recuva is looking in the wrong place. Is the disk FAT?


  3. Jeez, this is confusing. Are you using Drive Wiper from the Tools menu, or Wipe Freee Space from Options/Settings?

    The settings in your screenshot apply to Secure File Deletion and have nothing to do with wiping free space.

    It's difficult to grasp CC running for a long time and nothing is being done. Are you sure you're not looking at undeleted files?

  4. Colsh, if  you don't know whether the secure deletion is working or not then it's difficult to have any idea what's happening.

    On the rare imes I use secure file delete it works fine, with one pass. Years ago I ran a 35-pass secure file delete on a usb attached device and cancelled the job as soon as I could. After a few goes I caught the deletion in mid pass, so to speak. It was writing different patterns, implying that multi-pass is working. The last pattern of a multi-pass delete is zeroes, so it's very difficult to say whether one or more passes are being written.

    One quirk of overwriting is that by looking at the data you will never ever know how many passes have been run, it's just zeroes.

  5. You'll only get a preview in files that have an embedded thumbnail, and Notepad isn't one of those.

    Explorer gets the name and file size etc from the directory MFT record, it doesn't look at the MFT records for all the individual files. Recuva scans the MFT and - at a guess - takes the file size from the file's record. However on a recovery, which is a copy and paste operation, perhaps whatever request Recuva is making to retrieve the file gets the info from the directory, you are after all copying a live file. I don't know how Recuva or NTFS works at that level, I'm just trying to fit the theory to the facts.

    You could use HexDen (free portable hex editor) to find the clusters as identified by Recuva, and then copy the contents to a safe place. It's all rather tricky though. I would look at thre header info in Recuva first, as if it isn't what you expect then you may be barking up the wrong tree.

  6. OK, so it's secure file deletion. No matter how long it takes, are the deleted files being overwritten with zeroes? If so, no worry, as multiple wipes are, as every man and his dog will tell you, a waste of time.

    Perhaps you are running CC with a browser open and have checked the don't show this again box in the warning message, so browsing history is being ignored.

    If you have an SSD then stop wiping deleted files.


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

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

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

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

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

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

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

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

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

  • Create New...