Augeas

Yes, my computer is working fine. No, I don't boot from the USB drive. I don't have a Recuva64.exe either, just Recuva.exe. Perhaps there's some element missing from the Win 10 recovery files that is causing your problem. Recuva for me works just as it does for you. It appears that your problem occurs when you boot from the USB.

It's not that Recuva portable doesn't work on a USB drive, but that it doesn't appear to work for some users. I have no trouble with Recuva portable on a USB flash drive, so I can't reproduce this.

No, there is no easy way, or even a difficult way I can think of.

A normal and a deep scan will not find the same number of files (although with an SSD it will be close). A normal scan looks at the records in the MFT that are flagged as deleted. These records contain the file's name and cluster addresses, among other things. A deep scan will run a normal scan first, and then look at all the unallocated clusters on the device. When a specific file signature is found at the start of a cluster (and Recuva checks about 20 of the most common) this cluster and those following are presented as a file suitable for recovery. So there will always be more files found in a deep scan, unless the devce is an SSD and TRIM has wiped the clusters. There is no difference between saving the results of a scan and leaving Recuva open and acting on the results some time later. I would expect (and hope) that Recuva would check the state of clusters before overwriting them, even if it's only a few seconds after the scan has been run. Recovery is not so much of a problem, as it is not a destructive process and invalid data can be tolerated.

1) Who knows? 2) A normal scan will have file names and path if available. A deep scan will have files identified as [000123].jpg etc. These will follow the normal scan results.

2) A deep scan does not return file names, as it looks directly at the device's clusters which do not contain file name or path information. A deep scan runs a normal scan first so the file names from that will be displayed first.

No. This is for operating systems, or SSDs, that do not have TRIM implemented or enabled. On the assumption that you do, then the answer is still no. The option you want is Optimise, which will run a global TRIM on the SSD. I'd let Windows do it for you.

It does not mean that any particular file or files will be recovered. Just that there's no data limit on recovery.

Perhaps because the preview is embedded at the start of the file. Don't expect me to know the answer to everything.

All files found with a deep scan will be in Excellent condition, as a deep scan looks at unallocated clusters, which by definition can't be in use by any other file. A deep scan will only find the first extent of any file, as there is no method at the cluster level of linking extents together. This may result in the file being upopenable.

There's no limitation on recovery capability on any Recuva version.

I guess so. Your sister's HDD is not your laptop, is it? Just keep that HDD out of use.

Those ignored files are files that have not been deleted, live files from the install and whatever else has taken place. A deep scan with scan for non-deleted files doesn't make sense. Addresses for non-deleted files are held in the MFT, and a deep scan doesn't look at the MFT. If you have run a format which zeroes the free space then all this is of no avail.

I would advise against it, as with that amount of data you will almost certainly overwrite what you are trying to recover. You need a separate drive with al least as much free space as the source drive. Have you tried a scan with Scan for Non-Deleted Files checked? If you did a quick format this may be of more help than a deep scn, which does not return file names or directory structure, and only recoveres the first extent of any file.

I don't know why I typed c:\r, I should have said make the destination folder d:\r to emphasise that the recovery is to a different drive from the source drive. The recovered files are sent to a folder elsewhere, which makes the path name longer by adding the recovery folder name to the file names. The idea is to keep the recovery folder name as short as possible. To have 4,000+ names that are at, or close to, the file name length limit is rather unusual.

No, there's no differnce between the recovery capability of the free and pro versions. Assuming you have a valid copy.

I wish Excellent would be replaced with something else more descriptive, such as Not Overwritten, or Maybe, or perhaps Perhaps? It means that the file is not at this moment overwritten by another live file, not that the data is in any way valid or even useful. In Recuva Advanced mode have a look at the Header. This might tell you whether the data is in OO format (I don't know what that is, Google it). If it isn't then what you're recovering isn't an OO document. The data might have been overwritten by another file which has itself been deleted, or you're looking in the wrong place (cluster addresses invalid).

Cut your losses. Quick Format the drive, then run WFS.

Try to recover it to a folder in the root directory which has a name of one letter only, i.e. d:\x This will only add one letter to the file's full path name and with a bit of luck it can be recovered, then renamed.

In future runs forget three passes, one will do. Shooting a horse three times doesn't make it three times deader. Did you use WFS from Options/Settings or Drive Wiper? Slack space does not contain deleted file data, it contains what was there in the unused space if the file didn't completely fill the last allocated cluster. A deleted file cannot be reconstructed from slack space, by definition. CC WSF does not care about slack space anyway, or even files, as it operates at cluster level. There are some circumstances where WFS will leave some clusters untouched, and some small deleted files will remain unwiped, but I don't know if this applies in your case.

Do you mean a deep scan? If so then only the first extent would be recovered, and that can't be fixed, or guessed.

SSD? If so they have gone forever.

Assuming that it's NTFS then files 4gb and larger have their cluster addresses and some other fields in the MFT set to zero on deletion by MTFS. The file is effectively unrecoverable. Files less than 4gb can also have cluster addresses set to zero if they are, or were, heavily fragmented.

It's common in new installation to see very many deleted files from the install. Non-deleted files will have Non-Deleted (or whatever the description is) as their status. To stop showing non-deleted files uncheck the box in Advanced mode/Options/Actions. Free and Pro versions act the same.

There is an option in Advanced Mode to select non-deleted (live) files. This is unchcked by default.