Recuva fails to detect file minutes after deletion

[EM64]

I tried recovering a video from a folder (C:\Users\Username\Desktop) within minutes of deleting it and Recuva didn't pick it up in the deep scan, though it picked up older files.

Why is that? If it's because it's an SSD then nothing should have showed up.

[Augeas]

Because - probably - a deep scan runs a normal scan first, and a normal scan reads the MFT where the file names are held. The file names are listed, but the clusters which held the file's data should contain zeroes, or more correctly a read request will return zeroes (who knows what he clusters contain, they are unaccessible).

It is quite usual for files recently deleted being not found. A file deletion leaves the MFT record marked as available for reuse by any activity, and even opening Recuva writes a few files. I have a sneaky suspicion that NTFS reuses available MFT records held in memory first, so a recently deleted file's record is very exposed to reuse.

As you say, running a deep scan on an SSD is pretty much pointless, there's next to nothing to return.

[EM64]

So how is it that when I run even a regular scan on the whole C drive, tons of system/program files are found, but not this one? Seems like Recuva only find stuff that people aren't looking for. As such, what's the point of the program?

Edited June 6, 2021 by EM64

[EM64]

So does anyone know what the point of Recuva is?

[Augeas]

The point of Recuva is to recover previously deleted files, and the point of NTFS, which I assume we're dealing with here, is to ensure the integrity of live metadata and live user files. The two don't always go together.

Recuva reads the MFT and lists all records for files that have the deleted flag set. It doesn't select or exclude any files apart from those options chosen by the user. What you see is what there is in the MFT. If any deleted record has been reused by NTFS then the deleted file's information has gone and can't be shown.

With an SSD the process is the same but the outcome is different. Although the deleted file list is still shown very little data is recoverable, due to the way the SSD's controller handles deleted pages. Recovered files will contain zeroes, so using Recuva or any file recovery software on an SSD is likely to be futile.

However I have noticed a difference bewtween running Recuva when I had an HDD and when I moved to an SSD. On the HDD the list of files includes many recognisable user files, and there is a good chance of recovering many of them. With the SSD I see a large list of what appear to be system files, and a very short list (fewer than 20) user files. This is puzzling, but correlation isn't necessarily causation..

The only quick explanation I can see is that there are a larger number of dynamic file allocations and deletions taking place that are reusing the deleted user file records in the MFT, wiping out user deletions. When I moved to an SSD I also moved from Win 8 to Win 10. I don't believe that the SSD is relevant here, as it knows nothing of either NTFS or the MFT. NTFS version 3.1 has been the same on disk since Windows XP, so is Win 10 (or Firefox, or both of them) now upping dynamic file allocation? Is it Win updates? I don't know.

The point is that Recuva is doing what it always has done, reading the MFT and listing the deleted file records. That it isn't showing what the user might want it to is frustrating, but just how it is.

(Put as far as I know before every sentence.)