["it appears that we don't support this file format" problem]

47 minutes ago, Augeas said:

It's (probably) due to the way the SSD controller handles deletes, NAND flash architecture, and Windows TRIM for a start. When a page is deleted TRIM notifies the controller and the controller unmaps the page. Any reads of that page, as Recuva will do when if follows the cluster run addresses held in the MFT, will return a default page, commonly of zeroes or less commonly random data. Look up DZAT and DRAT on Google.

In the real world deleted data on an SSD has gone forever. The unmapped page is in limbo, and is wiped, sooner or later, by the SSD Garbage Collection process. Perhaps, just perhaps, a data recovery firm could recover some data, but I imagine it is an expensive process, if possible at all.

I don't believe there's any way that Recuva could retrieve deleted data from an SSD with TRIM enabled. It has physically gone.

Thanks for the additional Info Augeas.

I managed to find another set of these photos so i'm out of trouble for now.

While I was hunting info on the problem I came on something similar to yours about TRIM and thought I'd post here in case anybody wants to try turning off TRIM and having a go to see if it helps them.

=====================

Disable SSD Trim Before Undeleting SSD 
If you have opened the "Trim" function for the SSD, the possibility to recover lost files from SSD might be minor. Therefore, to recover deleted files from SSD, remember to disable Trim on SSD card in advance if you've turned it on.
Click the search box, type CMD. Right-click the Command Prompt, and choose Run as administrator. 
Type fsutil behavior set DisableDeleteNotify 1 and hit Enter.
After the recovery, you need to type fsutil behavior set DisableDeleteNotify 0 to enable TRIM.

=====================

["it appears that we don't support this file format" problem]

29 minutes ago, Augeas said:

If the drive is an SSD then you're unlikely to recover any valid data, although what you do recover should contain zeroes not a hex char.

If the O/S is FAT32 then the file cluster addresses are modified on deletion, so that they point to a different, and incorrect, cluster. Recovery is again unlikely.

Thank you Augeas.

Drive is, indeed, SSD and I was coming to suspect there was something different about them that messes things up when recovering.

OS is Win10 so file system is NTFS but that doesn't seem to have helped at all.

As almost all hardware is now being shipped with SSD instead of HDD is the company working on a solution to recovery from SSD?

 

Note to self "don't shift delete on an SSD!" :) 

["it appears that we don't support this file format" problem]

Hi.

I accidentally shift-deleted a folder, stopped, downloaded Recuva free version on a different PC and ran it from a flashdrive on the problem one.

Recuva immediately found the directory, sub-directories and filled the page with blank thumbnails that had the right names and sizes.

On running the "recover" part, I get a bunch of files that can't be opened with the subject error message although they all appear to be correctly titled and the right sizes.

If I ask GIMP to open some of the JPG then I get  some variant of "Not a JPEG file: starts with 0x84 0xe6" suggesting that all of the headers got corrupted even though we have practically zero overwriting in the time since deletion.

If anybody can throw any light on this I'd be grateful. Am trying to avoid using the laptop for now.

 

thanks