Augeas

You can't find txt files with a deep scan. If it's not found with a normal scan then it's unlikely that it can be recovered, or even exists.

There is, or can be, a log of files found before any recovery takes place, right click on the l/h pane and select Save List to Text File. I agree with many of your points, though. You can sort the found files by state, then recover the excellent files to a folder on your recovery disk, then do the poor to another folder, and very poor etc. If it's one folder you can filter by folder name in the File/Path box, and then sort by state. 7.6 tb of data is a huge amount, and 94k files is a modest amount. The files must be quite large.

Well who knows? This is a six-year-old thread, and a lot of software has gone under the bridge in that time.

My oh my, what a toxic IP address you have....

What do you mean only recovered 252? Did you try to recover the rest? What message did you get for the unrecovered files? Deep scan will not recognise any file structure, as this is a construct within the MFT, which you are not looking at in a deep scan.

Not a lot, I think. As I see it $BadClus is a throwback to the days when the O/S had to manage bad clusters, before that job was done more efficiently by the disk controller. $BadClus is a sparse file with a nominal size equal to the partition size. However it probably contains zeroes so it compressed to zero physical bytes. In Recuva Advanced Mode look at the Header pane for this file. It should be empty, indicating zero bytes. You can't recover a zero byte file, and it is pointless to try. Have you run a deep scan? You might be lucky (luckier) there.

Unfortunately that (i.e. the zeroes) is what appears to be in the clusters that the entry in the MFT points to. There is no way to recover what was there previously. I believe that javascript files are text files, so a deep scan would not help.

No, but you could do it yourself. Just create a series of duplicated folders containing small (a few bytes) text files with random filenames. If, or when, you have created the same amount of files as there are deleted entries in the MFT (Recuva helps here) then the MFT is 'clean'. Then delete those folders. Some people run Drive Wiper to wipe free space then cancel the job when the wipe MFT part is finished, which is easier. Or take the alternative outlook, why bother? As I'm sure you know cleaning the MFT is a process of overwriting the deleted entries with random data, nothing actually gets cleaned or removed.

Recuva (and most, if not all, recovery software) works by copying found data to another device. It does not reinstate deleted files on the original device. You should always recover to another device/partition to prevent overwriting data you are trying to recover. You might get away with recovering one or two files to the same device, but be it at your own risk.

I don't know of any restriction on device size, though I wouldn't run a deep scan on a drive of that size unless I was prepared to wait a very long time. You could also look at the NAS info on http://www.piriform.com/docs/recuva/introducing-recuva/what-it-can-and-cant-do

It's probably FAT32 so as long as you can get Recuva to see a drive letter then give it a go.

The problem - which exists for any recovery software - is explained here http://www.piriform.com/docs/recuva/recuva-quick-start/your-best-chance-for-recovering-files Unfortunately by the time the user has reached step 4 (in the original post) the damage has already been done, as Piriform explains. Searching for a recovery method involves many pages of hits on Google, looking at various reviews, how-to's and comments, and probably browsing forums such as this. So by the time the use choses Recuva - or any recovery software - he or she has overwritten several hundred or more entries in the MFT and just as many or even more clusters. Whilst recovery software could say that for the best chance of recovery download and install the software to another drive, by the time you get there you've already done the damage, especially if the recovery is on the system drive, where most of the hits take place.

I dunno, apparently I am banned from that forum.

I assume you mean in Advanced Mode, under Options/Actions, there is a box marked Secure Overwriting? Ignore this, as it only applies if you specifically select secure deletion, which you won't be doing. Just recover your files as normal (to another device), you will not overwrite any original files on the disk.

I don't believe so.

Not using Drive Wiper - which is useless on SSD's - would reduce read/writes even more.

Drive Wiper is a drive wiper. What's the point of selecting certain file types and then scanning the whole drive and overwriting any found when you could wipe the whole drive faster? In fact what's the point of this suggestion? Most of what is wanted can be done with Recuva, if you so wish. If you mean Secure File Deletion by folder, then that's an entirely different kettle of fish and has been requested several times.

Is this drive not an SSD?

Mr Google says that Smart data is not - at least not easily - enabled for usb connected devices. I'm no expert so it would be easier if you asked him yourself.

Do you really mean 8gb, or 8tb? If you only had space to recover half of your data then where are you going to put the other half? How did you select half the data? Did you use any secection criteria in the Recuva scan, or somehow highlight or check half the data found? If you ran a full scan in the first place then you didn't have to run another. Why did you not just select the other half of the data without rescanning?

Hmm. I warned you about spamming in your first post, and then you spam one of my posts. You shouldn't have pushed your luck.

Do you have any search criteria in the File/Path box, or are you specifying a particular file type? If so, get rid of it. You can do this whilst you still have the results of your scan displayed, and with a bit of luck the ignored files will be shown. Otherwise it's a new scan.

On file deletion FAT32 will set the first two bytes of the file's cluster address to zero. This will give an incorrect address for the file, and will retrieve invaled data. Is the first cluster address (shown in Recuva Advanced mode Info panel) under 65,535? If so this is probably invalid. There is no easy way to recover the data. You could try a deep scan, but this will only find the first extent of a file.

The ignored files are undeleted files or those that don't fit your search criteria. Scan again and don't enter any search criteria. You could also go to advanced mode and check Scan for Non-Deleted Files in Options/Actions.