Jump to content
CCleaner Community Forums

Augeas

Moderators
  • Content Count

    4,372
  • Joined

Posts posted by Augeas

  1. Drive Wiper runs a wipe MFT before a WFS, in as much as it overwrites the file names and data in the MFT. The total number of deleted files in the MFT remains the same, but the file names and data have gone. WFS in Options has no affect on Drive Wiper settings, and Secure Erase has no effect on WFS at all. So stick to Drive Wiper.

    I don't know what Disk Drill is returning (and I don't really want to know). I know that once CC Drive Wiper has overwritten the free space (and it does a preety good job at that) then that overwritten data can't be recovered by any means. Maybe DD is returning deleted file names (which should be ZZ.ZZ after running Drive Wiper) or maybe it is returning live files, but it cannot, under any circumstances, return any data that was there before being overwritten.

  2. It's difficult to give an answer without more details so we can only generalise. Did you use CC's Drive Wiper or WFS from Options/Settings?

    First of all Wipe Free Space is an overwrite operation, it does not explicitly remove anything. A WFS works by filling a volume's unallocated space with files holding zeroes and then deleting them, thus overwriting the data in free space.

    NTFS volumes have a Master File Table which holds a record for every file on the volume. These records are flagged when a file is deleted, and subsequently can be reused, but they are never removed from the MFT. A WFS may - depending on the settings - overwrite the file names in the MFT's records. After a WFS Recuva will still list all these deleted records, with file names which may be valid or not, and these files can be recovered (in as much as the file's overwritten data can be retrieved). But they will either be all zeroes or small zero files. In other words no use to anyone.

    I have no experience with Eraser, BCWipe or Disk Drill so I don't know what they are showing. I would say though that CC WFS does overwrite the vast majority of free space, and when that is done, with one pass, that data is not recoverable by any means known or available to the hoi polloi.

    Don't run WFS on SSD's. If they are reasonably modern with TRIM enabled then all unallocated clusters will return zeroes.

  3. You could save time, effort and a little bit of the planet by running one pass only.

    Are you using Drive Wiper or WFS in Options/Settings?

    You can't delete the MFT, CC will overwrite the deleted records with a file name of ZZZ.ZZZ or similar.

    Recuva scan will find all the deleted files in the MFT, including the ZZZ.ZZZ's. These files will be flagged as excellent and can be recovered, but they will contiain zeroes.

     

  4. Why would you want to run an Optimise every day? There is no way (that I know of) that Defragger, or the SSD controller, knows how 'unoptimised' the SSD is. An Optimise runs a global TRIM, or RETRIM, against all unallocated clusters as identified in the cluster bitmap, whether they have previously been TRIMed or not. Under normal usage the number of unTRIMed clusters should be zero, or close to it.

    TRIM is an asynchronous command triggered by file deletion and acts on the deleted file's data clusters. It is queued for low-priority operation. It does not need or send a response. The size of the TRIM queue is limited and in times of high activity some TRIM commands may be dropped. There is no indication that this takes place. Windows Storage Optimiser runs a monthly (default) Optimise to clean up the clusters that have escaped the TRIM on deletion. This RETRIM is run at a granularity that the TRIM queue will never exceed its permitted size and no RETRIM command will be dropped.

    There may be some user usage patterns that cause TRIM commands to be dropped, and a more regular RETRIM may be thought beneficial. But unless you think you are one of those users I would just let Windows defragger get on with it.

     

  5. Yes, Recuva acts 'in good faith' by following the field in the directory that holds the first cluster address. It can't possibly know if that field holds the correct value or not. The address field is truncated by FAT32 on file deletion because FAT32 is a souped up version of FAT16, and a workaround was devised to hold the larger address field required by FAT32. On file deletion the FAT32 values are wiped out and  the directory entry effectively goes back to FAT16. Don't ask me, ask Microsoft.

  6. If the file system is FAT32, which on a card it possibly is, then on file deletion the first two bytes of the data cluster address are set to zero. Recuva will follow this shortened address and recover what it finds, but it is obviously going to the wrong place and recovers invalid data. You can run the scan again and in Advanced mode look at the file info pane. If the cluster address is below 65,535 then this is an indication that the address has been corrupted.

    There's no feasible way to recover these files. A deep scan might just be lucky with some of them, as long as they are in one extent.

  7. In theory this is possible, in practice well, maybe.

    If the folder was on an SSD, forget it, the files have gone forever.

    Recuva does not recover folders, but files. The file list may show the owning folder alongside the file name, and the scan results can be filtered by the folder name.

    Assuming NTFS file system, the file names are held in the Master File Table. Deleted file names can be overwritten. If Recuva isn't showing the file names then they have been overwritten. The file data may still exist and might be found with a deep scan, but identifying the files would be difficult. A deep scan also only finds the first extent of a file, so files in two or more extenst would be unrecoverable.

    Files over 4 gb have their cluster addresses overwritten on deletion by NTFS, so although the file name might be found in a scan the data is not accessible.

    In short, if the normal scan isn't showing the file names, recovery is somewhere between difficult and impossible.

  8. You right click the offending file and select Overwrite Highlighted. A deep scan runs a normal scan first, so if you are selecting a file with a file name displayed, subsequent scans will still show this name (Recuva cannot amend system files). However the file data will have been overwritten with zeroes. With a file found by deep scan (no file name, just a number) the file will also have been overwritten and will not be shown again in a subsequent scan.

  9. The simple answer is that there are no records in the MFT flagged as deleted that match your selection criteria. A deep scan will not help as it doesn't return any file names, as they are held in the MFT. Securely deleted files (if I remember correctly, years since I've done any) are renamed so they also won't be found, and if they were they would contain zeroes.

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

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

     

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

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

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

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

     

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

×
×
  • Create New...