Augeas

The message is 'Already overwritten by an Existing File'. If you overwrote these clusters you would be overwriting a live file elsewhere, which is not a good thing. The image you can see s from the live file, not the deleted file. If you want to get rid of the entry in the MFT then run CC's Drive Wiper, or Wipe Free Space with Wipe MFT checked.

The state of non-deleted files is Not Deleted. You can sort this column and then select whatever group you wish.

Yes. it will look for non-deleted files, as long as it can see a drive letter. In Advanced Mode/Options/Actions check the fifth box down. As Mta says, success, or otherwise, may depend on how the SSD died.

It is saying that you have requested the recovery to be made to the same drive holding the deleted files. If this is done then the recovered files may overwrite the deleted files that you are attempting to recover, hence the warning. For such a large amount of files you should be recovering to a separate partition. Your third sentence made my brain hurt but Recuva will not delete or overwrite any live files on any partition whatever you do.

Directories are not recovered or restored, but rebuilt during the recovery process. Recuva willl rebuild the directory structure including deleted folders if they are still accessible in the MFT. If they are not then the directory structure will end with an ?. The owning directory for any file or folder is found from a refer-back address in the file's MFT record header. If this address does not find a valid directory then the directory cannot be recbuilt, hence the ?. Do you specifically want to recover a directory, or the files within it?

This has spam written all over it in rather large letters, and a link to a software crack thread. One thing it isn't, and that's a Recuva discussion.

I wouldn't worry too much about it. Even if all the data is re-written that's only a two or three write cycles at most out of each cell, and the cells are probably rated at 10,000 writes before failure. So if your partition is half full, and you rewrite your entire data every day, you still have around 60 years to go (less 3 days for your defrag).

Not really. Directories can't be recovered explicitly. If you can recover the files, just create a new directory and recover them to there. If you check Restore Folder Structure in Advanced Mode/Options/Actions then directories will be created implicitly.

I might be missing something, but is there a path to the builds page anymore? The only way I can find to access it it by typing in the url directly.

Nobody knows. It depends on the time that has passed since the deletion, and what activity has taken place on the volume. A deep scan might be lucky, see if you can match files with an xls (xlsx?) extension with a similar size and recover those. You might be lucky.

There's quite a lot on this subject in the forum. Briefly, Recuva goes to the cluster addresses in the file table and retrieves whatever is there. If those clusters have been overwritten at some point (but not now), or the address has been corrupted, then the recovered data is not worth whatever it's written on. You could try a deep scan, but this won't reinstate file or folder names.

I didn't know that Recuva recommended creating a virtual disk but either way it doesn't really matter. (Ah, Nergal's answered that one.) No software can tell with absolute precision whether a deleted file's formerly allocated clusters have been overwritten by another file that has since been deleted. I'm sure it happens all the time with browsing. Whatever Piriform chose to use as a descriptor doesn't alter this. File names come from the root and other directories and their existence isn't indicative that the file can be recovered. FAT32 systems have a trick up their sleeves on file deletion. The first two bytes of the file's start cluster address in the directory are set to zero, so Recuva, and all other software, will not be able to find the correct start of the file. If you are in Advanced mode and look at the info box for your files, you can see the start cluster address. If it is below 65,535 then it is possible, or even probable, that this is a corrupted address pointing to the wrong cluster. Recuva will recover data from the worng address which will be, as you say, trash. You could try a deep scan but there will be no file or folder names returned, so you will have to examine everything that's found to see if it's one of your lost files. To be frank as the files were lost many months ago the chance of recovery is in my opinion poor. I'm surprised that you seemed so het up about recovering your files, had a response within twenty minutes, yet it's taken almost five days to get back to the forum.

This is indeed one of the most confusing aspects of Recuva which Piriform have been told many times, and it would be so simple to fix. The Restore Folder Structure checkbox means that, if checked, the recovered files will be nested in their original folders, as far as that is possible. The Secure Overwriting drop-down list applies when you select a file or files from the scanned file list and then chose to overwrite them in place. It has no bearing on recovery at all, except that files can't be recovered when they're overwritten. It should be somewhere else, such as under the General tab. Just check the Restore Folder Structure checkbox. Ignore the Secure Overwriting list, it does not apply to recovery. You won't have to rescan if you check Restore Folder Structure.

If you cancel the restore then you don't have to rescan. Just switch to Advanced Mode if you're not there already and check the option as described. (I have also edited my previous post to add more info.)

The option is in Advanced Mode, Options/Actions, check Restore Folder Structure. Maybe this should be checked by default, but it isn't. You can still restore the folder structure within your original folder, which keeps the recovered files separate for reinstatement later. If a deleted folder has been reused then the files it contained will all be grouped within a default folder called ? - there may be many thousands of files there.

Unfortunately it is not possible to tell, as far as I know.

Use CCleaner's drive Wiper.

You can't create files, but you can create a folder in the root directory and put files into that. Do you (OP) mean that you created a folder called Downloads in the root directory, or a folder within the Downloads folder, which is at C:\Users\Names\Downloads?

'when it tells me a file is in "excellent" condition, and has not been overwritten at all, I expect to get the file back! ' Perhaps hope is better than expectation. The state of Excellent means that the clusters that were allocated to the file are not currently allocated to another live file. Recuva does not pass any judgement on the contents of those clusters. They may have been overwritten many times by other files which have subsequently been deleted. Recuva recovers what is there, not what was there many months ago. By the way if you left click on the State column header the state will be sorted, and all the Excellent files will be at the top. You can then easily highlight all the excellent files for recovery. As Mta says, what's the O/S, what's the file system? Did you run a deep scan? Did you use any selection criteria? Wizard or Advanced? It may be nothing, but I would have created a folder called Recovery or something siniilar on your recovery disk and recovered to that, instead of another virtual disk. You want to elinimate as much extraneous software as possible in a recovery.

I don't think that there is a next step here, apart from posting on the video repair software forum. You could rerun Recuva with Deep Scan and see if there are any playable results. You could check Scan for Non Deleted Files as well, I don't know what that actually does on FAT systems but it won't hurt.

I agree that if the drive can be seen then by all means run Recuva, it won't damage anything. I'm not sure what Scan for Non-deleted files does on a FAT32 volume (which the drive probably is), but leave it checked anyway. I would also do a deep scan. A format on a FAT volume has to clear the FAT tables to zero, so all extent and file length information will be lost. I suspect that the root directory will be cleared out too, so a deep scan is your best hope.

This seems like a prime example of Moravec’s paradox. We know that the drive is an SSD but the machine has a devil of a time trying to find out. I don’t know how Defraggler determines the drive type, but going on Piriform’s track record it will use a legit Windows function. In other words, it asks Windows instead of trying to do it itself. As far as I can find out this is done by running some benchmark, such as random read timings. (on the other hand I think that Speccy reads the disk model number for info.) You can see what Windows thinks your drive is by running msinfo32, and reset it if required with winsat.diskformal (all at your own risk). See https://www.itechtics.com/3-ways-to-determine-the-type-of-drive-hdd-or-ssd-installed-in-your-computer/ and https://shoprex.org/en/windows-change-hard-disk-drive-to-solid-state-drive-with-one-simple-command/ This might be all irrelevant of course, or simply incorrect, but it’s something to look at whilst waiting for Piriform.

Recovering files from a FAT32 suystem can be fraught. Try a deep scan and recover everything with a pic extension. If you are in Recuva Advanced mode, look at the Info pane and post what the starting cluster number is on a few of the unopenable files.

Remove all filters from the scan except the drive letter. In other words don't specify file type, folder or any limiting parameter. Then run the deep scan (It will take no longer than before). You will, or should, still get an ignored file count. This represents live undeleted files on the card. You should also get a list of found deleted files.

er, terrifying?