Why is this data seemingly gone?

Question

This question is a bit long, but people often prefer to have all the details instead of being required to ask for them, so I've included as much detail as possible.

I received a frantic call from a friend who had just accidentally deleted their Desktop folder in Windows using shift+delete.

Apparently, they only perform backups once a week (not often enough, IMO), and had an entire week's worth of work in that folder on their SSD.

Their Desktop folder was on a data-only NTFS partition, and no applications besides a file manager were open at the time. Their machine uses Windows 7.

They already had Recuva and Wise Data Recovery installed on a different partition, and had an additional third NTFS formatted partition with many GBs of empty space.

They didn't have any other drives available.

I recommended that they do absolutely nothing except run Recuva right away to undelete (recover) all folders and files from the partition that had the Desktop folder, and send the output to that third (mostly empty) partition. It turns out that Recuva has a serious bug that prevents recovery when the Desktop folder has been deleted, so they were not able to attempt an immediate recovery.

About 15 minutes had now elapsed since they deleted the Desktop folder. Their computer remained on during that entire time.

Given the lack of a successful recovery with Recuva, I then recommended that they do absolutely nothing except now run Wise Data Recovery to try to recover all possible folders and files from the partition that had the Desktop folder and restore them to that third (mostly empty) partition.

Well, it turns out Wise Data Recovery also has a bit of problem when the Desktop folder has been deleted. It took me about 5 minutes to figure out a workaround over the phone, and they were able to perform what looked like a full recovery using that tool.

Unfortunately 99% of the recovered files contain nothing but nulls.

I then recommended they perform a "deep scan" with Wise Data Recovery. After about half an hour, Wise Data Recovery completed its deep scan. My friend then performed the recovery again, but the results were no better.

There was much cussing on the other end of the line, and my friend's stress was palpable.

I had them try Recuva again, but that previously mentioned bug with Recuva is pretty nasty. It took me about 15 minutes to figure out a workaround for that bug, and then my friend was able to use Recuva to undelete the Desktop folder and all its subfolders and files (onto that third partition).

Unfortunately, again, almost every recovered file consisted of nothing but nulls.

I was a little surprised that neither tool could successfully recover the data. I was surprised because:

1. Very little time had elapsed since the deletion (thus if TRIM was enabled, it may not have had much to reallocate).
2. The computer was not turned off, placed in hibernation, placed in standby, nor was the user ever logged off.
3. My friend describes that machine as "lean and mean" with all extraneous Windows services disabled.
4. Shadow service was disabled on the data partition and the third partition.
5. No data at all should have been written to the partition that had the Desktop folder by any applications.
6. Besides the file manager, no applications were running.
7. None of the partitions were encrypted by the OS or any third-party software tools (though true, Journeyman Geek has pointed out the following may be relevant: Why does my SSD internally encrypt data, even without a password set?).
8. All restored data was written to a separate partition (albeit, on an SSD, I'm not sure how much that helps).

For over 1.25GB of deleted work, only about 80KB was recovered.

Question: Given such a short period of time since the deletion, and the lack of activity on the computer, why would those recovery tools mostly only find data blocks filled with nulls?

BTW, this question is long, and I appreciate you reading it. As of this writing, my friend's computer is still turned on and not being used. Ideas for recovery are welcome; if a new question is appropriate for that, please just ask, and I can post an edited copy of this question, with the focus on that topic.

Answer 1

Very little time had elapsed since the deletion (thus if TRIM was enabled, it may not have had much to reallocate).

Time elapsed is irrelevant, for two reasons:

1. By default, NTFS issues discards (TRIM commands) synchronously as soon as a file is deleted or truncated – you don't have to wait for the weekly "Optimize" task for it to happen.

   (You can feel this when deleting thousands of files and seeing the SSD at 100% – probably 99% of that time is spent in processing the TRIM commands, and disabling the synchronous discard through fsutil makes file removal go really fast.)

2. Probably the majority of SSDs implement the "Read zero after TRIM" behavior, where they don't merely mark the trimmed sectors "available", but immediately unmap them (and possibly physically erase the flash storage) during the TRIM command.

   After being discarded, those sectors no longer correspond to any physical flash storage (until written to again) and reading from them will cause the SSD's firmware to just immediately return zeros.

Honestly, losing a week's worth of work is still an improvement over losing 10 years' worth of work.

All restored data was written to a separate partition (albeit, on an SSD, I'm not sure how much that helps).

It would only have helped if the sectors with data hadn't been discarded using TRIM (or at least if "Read zero after TRIM" wasn't the standard behavior).

It's still the job of an SSD to maintain a consistent view of what data was written to what sectors, like any other storage medium would. So if partition 1 has some sectors that contain some data (e.g. your deleted files), those sectors will always continue to have that data until the OS writes something else; writing to partition 2 will never destroy data that's still being held by partition 1.

With TRIM it's different – the SSD considers the corresponding flash areas "available for re-use" after the sectors were trimmed and it's technically true that recovering to partition 2 may still overwrite flash areas that previously belonged to partition 1. But this only makes a difference if a specialist tries to recover data directly from the flash storage – those sectors already became inaccessible to the OS (and therefore, inaccessible to software-based recovery tools) as soon as discards were issued to them, and there is no SSD command to map the sectors back, so as far as software tools can see the data is already gone the moment TRIM was issued.

None of the partitions were encrypted by the OS or any third-party software tools (though true, Journeyman Geek has pointed out the following may be relevant: Why does my SSD internally encrypt data, even without a password set?).

The encryption done internally by the SSD is only relevant if you (or a recovery specialist) intend to physically open the SSD and read data out of the flash chips, bypassing the SSD's controller.

Otherwise, as long as the data is being read through the SSD's normal interface (i.e. using the standard NVMe or SATA commands), the SSD will transparently decrypt any data that's being read – after all, the whole idea is that the OS doesn't need to be aware of encryption happening – and your software-based recovery tools will be seeing exactly the same data as the OS is seeing.