All restored files with cluster(s) allocated are zero (= binary 00 bytes)

[apo13]

Dear professional restorers,

 

do you please have some help for me ?

 

On a Windows 7 Pro system, with NTFS file systems,

I accidentily deleted some file folders (about 500 MB)
on a Samsung SSD EVO 850 250 GB
 

I immediately did shutdown the system, and I now use a backup boot system.

 

With Recuva, I changed these options against default settings:

• Tree View
• Deep Scan
• Restore folder structure
• (Simple Overwrite) (stays default)

 

Then I tried to restore one of my lost folders ...

all files within this folder show restore state = 'Excellent'.

 

Files with looking at 'Recuva-Info':

Comment: No overwritten clusters detected.

are all fully restored,

 

but ('Recuva-Info')

ALL Files with any "cluster(s) allocated"

e.g. "1 cluster(s) allocated at offset 95273"

 

are all not (fully) restored.

 

In detail:

• The file structure is fully reconstructed,
• flat files are created with their original filenames,
• file sizes are identical to origin sizes,
• but the contents of the files are all zero (= binary 00 bytes).

 

The 'Recuva (binary) Header view' shows only zeros (binary 00 bytes),

I looked with another hex editor at the files,

the inside contents of the files are all zero (binary 00 bytes).

I'm sure, the files are still on the SSD.
So, what do I do wrong ?

 

Actually I downloaded the actual Recuva free version rcsetup152.exe,

would it help, to get the 'Recuva Professional Version',

to overcome these problems ?

 

Any advice from you will be really appreciated,

Wolfgang

[Augeas]

Do you have TRIM enabled? If so, bad news.

 

Recovery in Recuva free and professional is exactly the same, so there would be no advantage in recovery by using the pro version.

[apo13]

|| TRIM enabled?

||

Uhh, mhmm, well, not intentionally.

 

C:\Windows\system32>fsutil behavior query DisableDeleteNotify

DisableDeleteNotify = 0

 

I'm innocent => Microsoft (or Samsung) did it!

 

Dear Augeas, thank you für your advice,

it looks that this could be the reason ...

 

It helped, that Recuva did reconstruct the filesystem and (empty) files,

so I can better fill the gap and bridge to my 2 day old backup.

 

In the end: is there with TRIM enabled no chance anymore: ... ?
 

Regards, Wolfgang

 

PS: Recuva Suggestion

From the perspective of Recuva, reconstruction was fully done,

but maybe should Recuva indicate in its file status,

if files consist of only zeros ? ...

[Augeas]

Hi Wolfgang. When TRIM is enabled a delete will cause the SSD controller to remap the file's clusters (or pages) to a default empty page of zeroes. There is no way to retrieve the old pages containing the data. Bad news indeed. But you have a backup, unlike many.

[apo13]

Hi Augeas,

 

thanks again for your reply.

 

This means for SSDs: recovery will/would be impossible.

 

One last, final cry: ... ;-)
 

The 'Recuva-Info' tells us about cluster offsets

e.g.:

 

Filename: jquery-2.1.4.js

Path: J:\JavaScript\...

Size: 242 KB (247.623)

State: Excellent

...

Comment: No overwritten clusters detected.

Data streams: 2

jquery-2.1.4.js

jquery-2.1.4.js:Zone.Identifier

 

61 cluster(s) allocated at offset 95205

 

What does e.g. "offset 95205" mean ?

Would be no remapping (by Recuva) possible: ... ?

 

Thanks,

Wolfgang

[Augeas]

This is information held in the Master File Table (MFT) that NTFS uses to identify which clusters are being used by the file. NTFS was written for disk storage, and it means that 61 clusters starting at cluster number 95205 (from zero) are allocated to the file.

 

The SSD has what's called a Flash Transition Layer (FTL), and this translates the logical cluster number (95205) into a physical page number on the SSD which could be anywhere. When the file is edited a new page is written on the SSD but the logical cluster number in the MFT remains the same because the FTL remaps the logical cluster to the physical page.

 

All this translation is done entirely within the SSD controller. Neither NTFS nor Recuva can see this, or change it in any way. In this way the storage device can be SSD, HDD, or flash drive, and NTFS will still work the same.

 

The information Recuva is using comes from the MFT, which holds the logical cluster addresses, and whether the data is overwritten or not. The SSD doesn't know of the existence of the MFT, or any file, it just reads and writes clusters when told to by NTFS.