Augeas

A deep scan will run a normal scan first, which is possibly where all the unmentioned files came from. A normal scan will return any file type, with or without an extension, where a deep scan will - as far as I can tell - only return those file types mentioned in the link in post 3. How long can a pc stay on? I dunno, five years?

The file names begin with an underscore which indicates that the file system is FAT32 and they have been legitimately deleted. On FAT32 the directory entry for each file holds the offset in the FAT of the first cluster of the file. On deletion the first two bytes of this address is set to zero, so any cluster address that is larger than 65,535 will be corrupted, and will now point to a cluster far closer to the start of the FAT. This cluster (and possibly many if not all of the clusters under 65,535) is likely to be occupied by another file or files, which is why you are getting the message 'This file is overwritten by...'. Recover will retrieve the clusters it finds at the corrupted address, and it's no surprise that they are not valid files. The effect is that once you have filled the first 65,535 clusters - just a quarter of a gb with 4096-byte clusters - any file subsequently created will not have a valid start cluster address if it is deleted. This is a characteristic of FAT32 and no software can resurrect the corrupt addresses. If you switch to Advanced mode in Recuva and look at the Info pane for the files you should see a start cluster number of under 65,535. If you run a deep scan you should find the first fragment of the files, with the mp4 extension but no file names. The drawback is that only the first fragment can be found this way, as subsequent fragments are not identifiable. So not very good news.

Can't help with PM, I used it a couple of years ago, it may help to repair the partitions so it's worth trying before having to format.

I don't think so. I should try Partition Magic and see if it really is magic. I have used it in the past to manipulate partitions with some success.

Recuva will recover whatever is in the clusters (that were) allocated to the file. It doesn't validate the contents, which may have been overwritten sometime. You can't really do much apart from a deep scan.

I've split this into its own thread as tacking onto a nigh-on six-year thread is not relevant. My bet on this is that the OP is looking at non-deleted files. Recuva will show these as a count (i.e. 318,000 files ignored) or as a list if Show Non-Deleted Files is selected.

Probably screwed, as far as Recuva is concerned. If it can't determine the file system then I can't see it going any further. Have you tried a deep scan with no other options selected? You could try Partition magic to attempt to resurrect your file system. It does some amazing things. Your cards are probably FAT32.

It's unlikely that Piriform will respond here. We don't know how large the card is or whether it's FAT32 or exFAT, or even how Canon implements that file system. If it's exFAT then that file system is proprietary and there's not a lot of info about what happens on file deletion. My guess is that locating the file's original clusters is the problem. FAT32 is notoriously difficult and exFAT is more sophisticated than that.

Because a wipe entire drive will format the drive first, which you previously said took four to five days. After this format Drive Wiper will wipe all the free space. You can do a wipe entire drive if you wish, and post back next week.

This thread is too much of a mess. Windows 9, disappearing files, VHD problems? Who knows what the Russian question (No one knows how to fix it?) refers to? One topic at a time, and a few more details please.

First of all I would scan the drive with Recuva (after the format) to see if there are any old file still visible. If not then I would consider whether you want to run a long wipe free space. If you do run a wfs then open Tools/Drive Wiper. Leave Free Space Only and Simple Overwrite (1 pass) in the two top boxes, and select the drive to wipe. Press Wipe and away you go. Three tb will take some time to wipe. You don't need to worry about any other Cleaner options as Drive Wiper will only run Drive Wiper.

An NTFS format (Vista onwards) will zero all clusters and create a new MFT, so there should be no trace of previous activity.

You can't do much more with Recuva than a deep scan. Don't put anything in the filter boxes, search for everything. I've no idea what happened to the card, it looks as if it's been low-level formatted, and if so you will lose everything.

If you have a 5 tb SSD then I think you should be very happy. To get rid of those files you need to run CCleaner's Wipe Free Space from Drive Wiper.

The specific answer to your suggestion is that TRIM doesn't write ones (or zeroes, or anything) to an SSD page. It flags that page as being available for garbage collection, which is a process that 'empties' the page of data, i.e. sends all those electrons back to the right side of the gate. An empty SSD cell is interpreted as a one. However you will not see a page full of ones as the empty pages are held back and used as new pages when data is written. Thus every page you will ever see will always contain at least one zero. If you read an empty page the SSD controller will generate a default page of zeroes and return that. (The process with MLC SSD's is rather more complicated, but the principle is the same.) So the data pattern when wiping an SSD is irrelevant. Wiping an SSD is also irrelevant, as you can't overwrite an SSD page (it does have some use on non-TRIM enabled devices, which are a little long in the tooth now). Somebody else can comment on TRIMming a raid array, as I'm not au fait with that technology.

Check Scan for non-deleted files, you should then see everything.

I think I used DiskInternals Linux Reader, which does not assign a drive letter. You could try Ext2Fsd, which does assign a drive letter (ext2fsd.com).

The total number of files found includes all files, live and deleted. If you remove any filters then all deleted files will be shown.

The last time I faffed about with ext4 it wasn't able to be mounted under Windows, so I had to use a piece of freeby software to act as an intermediary. Not very convenient, and I don't know if Recuva would be able to handle it, but better than formatting to NTFS (you would have to do a deep scan). It would help if the release notes were a little more expansive.

If the card is FAT32 then there are a couple of reasons why this might be happening. On file deletion the file system will zero the first two bytes of the cluster address, so any file recovery software following this address will not find the file. In Recuva advanced mode look at the Info pane. If the start cluster address is under 65,550 then this is likely to be the problem. A deep scan will most likely find the start of the file, but..... On file deletion FAT zeroes the cluster chains in the allocation tables. If the file is fragmented then there's no way to follow the links between fragments, as they no longer exist. Some software will attempt to 'guess' where the fragments are, but not Recuva. Deep scan will only find the first fragment of a file. There's no easy answer to these problems.

Because it's not possible, using Windows API's, to overwrite file names. The only way to do it is to run a CC wipe free space. If you really mean File Allocation Table then in FAT drives the file names are held in the directories, and the first letter of the file name is amended on file deletion. Recuva can't access or amend these file names (as far as I know, I'm no FAT expert).

This has been suggested several times before. I think that the main reason why Recuva doesn't have this feature is that the scanned device is volatile, the scan results are more or less obsolete as soon as the scan has completed. I assume (and hope) that Recuva checks that the space occupied by any files selected for secure deletion is still free before it actually overwrites it. If the info is several hours, or days, old then it could be a 'write' mess. (I've been here too long, having to resort to puns.) Recuva takes time to cancel because a cancel leaves a search list of files found so far, and that takes time to produce. As for taking too long to scan, Recuva was developed when disks were around 150 gb or so. These 3 tb and up disks are just too large for anyone.

What file system is your F drive?

A deep scan runs a normal scan first by default. If the files you are looking at come from the normal scan (they will be listed first, with full file names), and if the file system is FAT32, then the cluster addresses may be amended on file deletion making file recovery very difficult. If the files are from the deep scan (no file names, just a number) then the files may be fragmented. Recuva will only recover the first fragment of a file. In both these circumstances it is not possible to recover the files successfully.

Twelve million files is rather a lot to process. I usually cancel Stage 2, it doesn't seem to make much difference (or any I can notice). Recuva works at logical drive level, one partition at a time.