Jump to content

Augeas

Moderators
  • Posts

    4,542
  • Joined

Everything posted by Augeas

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Why not go to login and request a password reset, assuming you can't remember the old one after 13 years?.
  8. The old account username would be a help.
  9. 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?
  10. 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.
  11. 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.
  12. I wonder why Ericar's posts are so spammy.
  13. In theory yes. However no software can guarantee to recover a specific file. Just try it, it isn't destructive.
  14. Augeas

    Recuva

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

    Recuva

    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?
  16. 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?
  17. 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.
  18. (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.)
  19. No matter how long it takes, are the deleted files being overwritten with zeroes? How are you overwriting individual folders/files?
  20. 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.
  21. 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.
  22. In Recuva advanced mode have a look at the file header. Does it have a recognisable file signature? Is it all zeroes? Does it look valid or garbage?
  23. 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.
  24. 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.
  25. 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.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.