Jump to content
CCleaner Community Forums

Augeas

Moderators
  • Content Count

    4,382
  • Joined

Community Reputation

1 Neutral

About Augeas

  • Rank
    Moderator

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Gender
    Not Telling
  • Location
    Where Stuff is made, UK

Recent Profile Visitors

4,302 profile views
  1. I recommend 'Stop Forum Spam'. You have a bit part in it.
  2. Yes, it doesn't look too good. If the file headers aren't there then I doubt if the rest of the file is there either. It's probably due to the formatting with the Win10 upgrade. I don't know how you managed to retrieve the file names, they should have gone with the formatting too. The excellent state just says that no other file is overwriting them, not that the file contains any data that is of any use to the user.
  3. Is the formatted drive an SSD? If so the files are very likely gone forever. How did you find the deleted files after a format? The MFT (assuming NTFS) would have been recreated. Did you select Scan for Non-Deleted Files in Options/Actions? In the Recuva scan (you can run it multiple times with no adverse effects) go into Advanced Mode and look at the file header pane. Is the header all zeroes, or something else?
  4. It's true that in Drive Wiper there is no option for selecting a wipe MFT, but that's because you get it anyway as a freebie. If Drive Wiper WFS is run you will see a Wiping MFT message at the start of the run. It could be argued that a WMFT is part of WFS, as some file data is held in the MFT record and is not wiped by a 'normal' WFS. As far as I know the WFS parameters in Options/Settings have no effect on Drive Wiper. The Wipe Alternate Data Streams and Wipe Cluster Tips are settings for Secure File Deletion, which is not part of Wipe Free Space. I think that the reason why W
  5. To clarify a little, as I understand it Nukecad, WFS in Drive Wiper runs a wipe MFT before the disk wipe. Unless things are different in Custom Clean, but I never run any WFS to test it.
  6. 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.
  7. 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
  8. 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
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. 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
  14. 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.
  15. 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.
×
×
  • Create New...