Augeas

Well, with TRIM enabled, which should be the standard on SSD's and O/S's in the last few years, every deletion (either shift/del or empty recycler) becomes a secure delete, in as much as the deleted pages are gathered up by the SSD's garbage collector and wiped clean. The old data on those pages is then beyond the reach of humankind. Occasionally, when the pc is stressed, TRIM commands can be dropped, so a defragger optimise could be run every few months or so. An Optimise issues a device-wide TRIM. You can run a Recuva deep scan to check all this. There will be thousands of file names found from the normal scan (which is run as part of the deep scan). These names are held in the MFT which can't be TRIMmed, of course, and they will still contain the addresses of the data clusters/pages. In Recuva Advanced Mode look at the file headers: they should all contain zeroes. There should be no files found with the [000123].ext naming format as these are the deep scan files, which should not exist. The moral is, just do normal file deletions and run a defrag Optimise every now and then. Don't use secure file deletion, don't run wipe free space, and for those who don't believe any of this and insist on doing all that, never, ever select more than one pass overwrite. There is one caveat: Small files, say 700 bytes or fewer, will bypass all this as they are held entirely in the MFT, so TRIM will not catch them. Most will be overwritten as newer files are allocated in the MFT. If this is a worry then an occasional WFS with one pass could be run, either from Drive Wiper (easier) or Options/Settings with Wipe MFT checked.

Instead of asking you whether all the boxes have been ticked, can you try a WFS using Drive Wiper, one pass?

Are these deleted files small, say under 10 or 12k? If so it fits a theory I have why some files aren't wiped. It's just that, a theory. I would select them all in Recuva and securely overwrite them (one pass will do). To overwrite file names you have to check Wipe MFT in CC Options/Wipe Free Space, or use Drive Wiper which does it by default. That means running another WFS which may not be worth it, the majority of the file names will be overwritten with use anyway.

I'm running Recuva portable and it used to take years to open. I excluded Recuva and CC from my a/v checking and both open very quickly now.

What has already been wiped will remain wiped - it won't become unwiped because you cancelled the process. Whether the 80% is accurate or not is anyone's guess.

When you ran WFS in the past was it on NTFS or a FAT32 volume? (Going back to posts 2 and 3, checking Wipe MFT has no effect on a FAT volume.) One of the wonders of FAT32 is that on file deletion the first two bytes of the file's address are set to zero, so that when Recuva, or any software, follows this address it goes not to the actual start cluster of the file but to some point far closer to the start of the volume. What you are seeing in the file's header may be part of the root directory, or another directory, which is still a live file. Going back to the file names, I can't see how CCleaner can alter or remove deleted file names from FAT directories, but that would always have been the case. I don't have any FAT volumes so I can't run a WFS to test it. Perhaps some other FAT user can chip in.

There are two immediate hypotheses here: either recovering the files to the same disk as the source overwrote the source, or the files were corrupted before the recovery started. Unfortunately it's probably impossible to say which one occurred. Equally unfortunate is that no overwritten data can ever be recovered. There's a lot of info missing as well, how large is the disk, is it HDD or SSD. NTFS or FAT32, how much free space, how large are the video files, etc. 'Prior to this I could recover these videos no problem' - did you recover them, what does this mean?

Please stick to one thread per subject, just type what you want to say in the Reply box.

I'm not sure (I can't remember since it's so long since I ran one, and I don't have a FAT partition to test it on) how WFS operates on FAT32 but the file names are held in directories, not an MFT, so they cannot be purged. Excellent condition simply means that no live file currently overwrites the deleted file's clusters. If you look at the file's header (in Recuva Advanced Mode) then you should see all zeroes. One pass is sufficient for an overwrite, three passes doesn't overwrite any more thoroughly than one, and it's far quicker.

No. System Restore 'points' are not just single files that can be restored, even if they were then I don't believe that NTFS would allow the recovery system to be tampered with. A Sys Restore point has many components, including registry entries, so it is not possible with Recuva to find them and restore them.

I am assuming that nothing has changed with WFS in recent releases, as I don't run it very often. Wipe MFT will still leave the same number of filenames, but they will, or should, be random ZZZ.ZZZ's. This applies to NTFS. FAT32 doesn't, of course, have an MFT, and I can't remember what CC does on a WFS.

This is normal if you are running WFS from Options/Settings and you haven't checked Wipe MFT. Either check it or use Drive Wiper.

Recuva will recover candidate files from FAT32 to NTFS and vice-versa. However this does not necessarily mean that you will find the files you are looking for, or that they will be in a recoverable state. You must be able to access the source disk by drive letter in Explorer with the relevant permissions.

At a guess, the drive was formatted as NTFS. The TV probably doesn't recognise NTFS as it is a proprietary file system that you have to pay to use. The TV may well have formatted the disk as ext3. The Windows format probably went back to NTFS. I don't know whether either of these formatting exercises would have zeroed all clusters. What is certain is that a normal scan won't find any but system files. A deep scan will look at all clusters on the disk. That's how it finds data (or not, as the case may be). I should try to let it finish, especially as you say you have found some pics. Are they lost user pics, or some other pics? When the deep scan has ended you could try a normal scan with Show non-deleted files checked, but I wouldn't put any money on success. It will run quickly though.

The Files Found count includes live (undeleted) as well as deleted files. At the bottom of the page there are Found and Ignored counts: what are those figures? Did you run a deep scan? Do you have anything in the Filename or Path box, or did you choose any file selection criteria? FAT32, though less sophisticated than NTFS, can be problematic when attempting file recovery.

Yes, I see your point. But the second analyse is a lot faster, isn't it.

SSD's are different from HDD's in as much as when the device is told that a cluster (page in SSD terms) is no longer required it is removed from all practicable chance of recovery. For file deletion, the TRIM command tells the SSD that the cluster is no longer required. For a device format (quick or full) I assume that a TRIM is run on all the clusters: I'm not certain about that, but it seems logical that it should be. I believe that TRIM is integrated into all file system operations. TRIM on clusters makes the SSD controller move them out of reach of any file system command. Recuva should show just the system files used during the Win10 install, nothing from any previous use. I don't think that your chances of recovering the old file are much above zero. Recuva free, by the way, has the same recovery function as Recuva Pro.

Secure File Deletion, if you're deleting live files. Wipe Free Space with Wipe MFT checked, or Drive Wiper if you want to remove already deleted filenames. This is for NTFS, post back is you have FAT drives.

Your posted question was from seven years ago, so please let's stick to one relevant thread. There isn't a way as far as I know, or can think of at this time of night.

Recuva will recover whatever is in the clusters pointed to by the file entry, or in the case of a deep scan, whatever is found directly at the cluster level. It's a byte by byte copy. If what is recovered is rubbish, then what's on the disk or card is rubbish. Recuva can't make any decision on the veracity of the data. Both FAT32 and NTFS destroy certain elements on file deletion which makes recovery more difficult.

The files found includes live files and those excluded by whatever options are used, exclude zero length files, for instance. That's all there is on the card, if you can show why you think that there's more then please do. With such a small amount of files found stage two and three are likely to pass very quickly. Those two stages don't reveal any more files, just provide more details.

Yes, it's called CCleaner. Use Drive Wiper, or Wipe Free Space with Wipe MFT checked.

Excellent condition means that the file's clusters aren't being overwritten by another file. When the clusters are overwritten by Recuva, the program can state that the file has been securely deleted/overwritten/removed. However if Recuva is stopped and restarted, it has no way of knowing that it overwrote the file previously, so it states that the file is in excellent condition.

Yes, use the free CCleaner Drive Wiper function, as indeed you are discussing in your other post.

I haven't experienced this myself, perhaps it would be better to read through https://forum.piriform.com/?showtopic=40720 for a start, or try the many hits on Google for this problem.