7

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.

11
  • 3
    Its been years since I did forensics but I was told (and read some papers long forgotten) that SSDs had some quirks. Modern ones do things like encrypting or scrambling the drive - which... improves reliability, and I read entirely contradictory papers on SSD recovery.
    – Journeyman Geek
    Oct 26, 2022 at 11:10
  • 3
    Recovery from an SSD, as you can imagine is an entirely different beast. You can't just scan every sector and look for fragments, and use algorithms, to patch together files. SSDs constantly mark new and old seectors available while making other sectors unavailable. There really isn't a good solution to this problem.
    – Ramhound
    Oct 26, 2022 at 11:13
  • @JourneymanGeek I was hoping you might reply. Thanks. I forgot to mention that the drive was not encrypted by the OS (I'll make an edit to the Q) or intentionally hardware encrypted by the drive. I still don't consider myself an SSD expert (ya, I know, it's 2022), but the "scrambling" you mentioned (combined with Ramhound's comment) does make sense as a loose approximation of the implementation of current SSD technology. Oct 26, 2022 at 11:21
  • @Ramhound Thanks so much for taking the time to read the Q and reply. I'm glad you did. I think your last sentence, although sad, may sum it up: "There really isn't a good solution to this problem". If so, that's a big downside to SSDs. Your comment implies that you can't even just scan every sector looking for specific strings. Am I understanding you correctly on that? Oct 26, 2022 at 11:24
  • 1
    Another good reason to Not use a SSD for data storage
    – Moab
    Oct 26, 2022 at 11:29

1 Answer 1

5

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.

9
  • Oh wow, I received responses from Journeyman Geek, then Ramhound, then user1686... the trifecta of top-notch Super User gurus, IMO. I sincerely feel much gratitude to you all. Your answer is very helpful and your second point reminds me of something I read, but wasn't on the top of my mind... that modern SSDs often implement "Read zero after TRIM". I forgot about that, and the results my friend experienced indicate that this could be the case. Oct 26, 2022 at 11:28
  • 2
    I feel really sad for my friend (they are literally in tears). They just realized that they were backing up absolutely everything besides their Desktop folder every week, but that particular folder was not included in backups due to a UI issue in their backup tool (they thought it was being backed up, but it was not). So it turns out they lost nearly 2 years of work on many important documents. They said they have probably lost 500-1000 hours of work that was yet to be published. Oct 26, 2022 at 11:34
  • I just thought of something... why would almost all the data be gone, but not all the data? Oct 26, 2022 at 11:40
  • @RockPaperLz-MaskitorCasket - minimum sector size. I got doubts 500 KB is anything but a text document. Even your basic Word document is larger than 500 KB
    – Ramhound
    Oct 26, 2022 at 11:45
  • 1
    My only guess is that the recovery tool might have scraped them out of the MFT. "About 500 kB recovered" sounds like it consists mostly of very small files – on NTFS filesystems, when a file is below ~1kB (not sure of the actual limit), it can actually be stored "resident" within the MFT, without having a separate data allocation.
    – user1686
    Oct 26, 2022 at 11:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.