Jump to content
CCleaner Community Forums


  • Content Count

  • Joined

Everything posted by Augeas

  1. In the first example the file's data is held in a separate cluster. In the second the data is held entirely within the MFT record for the file. The cluster can be overwritten by another file allocation, but the MFT record can't be overwritten until that record is reused. I don't know, of course, what has happened to the data cluster. It could have been reused by a temp file (internet search etc) which has been subsequently deleted. In any event the old data has almost certainly gone.
  2. I never knew there was such a word as Drobo until I saw this thread. Recuva gets its information from the MFT - this holds the file names etc and the data cluster addresses. Recuva will copy what's at those addresses (the data within the clusters) when it does a recovery. It's a copy of what's there, there's no concept of the data being good or bad. If the headers are zero then it's likely that the rest of the file is zero, and thus, from a user point of view, unrecoverable. From NTFS's point of view there's no reason why the data should be zeroed, data clusters are not touched on fi
  3. Are the drives in the Drobo SSD's? Have a look at the header info in Recuva Advanced mode. Are the headers all zeroes, or random data, or what? What file system is the Drobo? How large are the video files? This might be interesting.... https://recoverit.wondershare.com/repair-video-file/how-to-repair-mp4-video-header.html
  4. CC saying an HDD as an SSD is an error. I don't know how CC identifies a drive, whether it interprets the model type or uses some other method, but sometimes it goes awry. However (and many others will tell you this) you don't need to do multiple passes on an HDD overwrite, one will do. No commercial organisation in the world claims it can recover once-overwritten data, and if you're worried that MI5 might be bashing in your door then I respectfully advise you to surrender to the authorities.
  5. 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
  6. 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.
  7. 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.
  8. 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 o
  9. The ignored files are non-deleted, or zsro byte or system files. You can show these by going into Advanced Mode and checking the various boxes in Actions/Options.
  10. 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.
  11. 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 e
  12. 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 diffic
  13. Why not go to login and request a password reset, assuming you can't remember the old one after 13 years?.
  14. The old account username would be a help.
  15. If you checked all the boxes in Actions/Options then you wil see non-deleted files as well as deleted. If you try to overwrite a non-deleted file the action will be greyed out. Recuva doesn't work in the background. You don't have an SSD do you?
  16. 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.
  17. 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.
  18. I wonder why Ericar's posts are so spammy.
  19. In theory yes. However no software can guarantee to recover a specific file. Just try it, it isn't destructive.
  20. Augeas


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


    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?
  22. 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?
  23. 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 ov
  24. (LesN, do not put your confusing posts in this thread. I have created a new thread Cleaner Drive Wiper in CC Bugs: your questions can be addressed there, and Colsh's here.)
  25. No matter how long it takes, are the deleted files being overwritten with zeroes? How are you overwriting individual folders/files?
  • Create New...