Issue is as follows:
1) used the software "crap cleaner" to clean temp files from SSD main drive (Drive c:)
2) by mistake used the flag to delete the "Downloads" files - which is basically C:\Users\username\Downloads -> (153 files were deleted)
3) Run "recuva" to scan the entire drive -> then scanned the files -> marked the C:\Users\username\Downloads -> target set to drive D -> all files were restored with their names,file size all looks fine however -> can't open a single file ,all corrupted /invalid (those are JPG and PDF files mostly)
is there anything to solve this or being on SSD drive due to trim etc all is lost?
why the files were recovered so nicely but can't be opened.
any help will be welcomed.
I assume there's no backup which is why you are trying to revover them.
Recovering deleted files from a SSD is almost impossible, almost because there might just be a very slight chance.
As yu suspect TRIM and wear levelling come into play.
You say that the recovered filesizes look about right, but did you have 'Secure Delete' set in CCleaner which would have overwritten the contents?.
Have you tried opening one in a text edior/hex editor to see if it's all zeros?
You could try Irfanview which can often open damaged image files that other viewers won't open.
If it does open then 'Save as' will save it correctly so that other viewers can then open it.
The PDF's would be another issue though and I wouldn't know what to suggest.
thanks for your quick reply "nukecad"
crap cleaner wasn't set with "secure delete"
the recovered files looks to be in normal size and when opening via notepad++ , it is NOT all zeros ,i can ofcourse attach an example file here if needed...
this is why its strange the files on the surface looks fine...
i will try your recommended app https://www.irfanview.com/ and will update.
If files have been deleted from an SSD with TRIM enabled - as you most likely have - then as Nukecad says recovery is nigh on impossible. The file size and cluster information will still be available as this info is held in the MFT and is not destroyed on file deletion. Recuva will follow this info and recover (i.e. copy) the data it finds.
The return from reading a TRIMed file is zeroes. The exceptions are if the file is very small (under say 700 bytes) and is held entirely in the MFT; or if the file is larger and its clusters have been overwritten by a subsequent live file allocation, when Recuva will be recovering data from that live file.
Irfanview is good, but I very much doubt it will help here.
It is interesting that the recovered files are NOT zeroed.
New data being written where they used to be is a possibility, though more often I'd associate that with HDDs.
I'm still trying to grasp just how this stuff works with SSD's so don't quote me, but 'Dynamic' and 'Global' wear leveling can also move old but still existing data into the storage blocks where the deleted data used to be.
(Probably misleading but think about it a bit like trying to recover from a HDD that has been defagmented after the files had been deleted, Recuva can 'see', from the Logical Block Address still held in the MFT, where the deleted files used to be on the drive but it can't tell if something else has later been moved into that address).
It's further complicated by the fact that the SSD built in controller doesn't actually store things at the LBA, instead it maps the LBA to a Physical Block Address where it has actually put the data., either when first written or when moved for wear levelling.
In the end though the thing to take home is that it's almost impossible to recover deleted files from a SSD.
Just to note that by contrast you can usually recover deleted files from a thumbdrive, I've done it myself, they don't have TRIM or wear levelling. (although some high end industrial thumbdrives do have them).
Let us know how you get on with Irfanview for the images.
The problem with trying to diagnose a er.. problem is that we can't see all the data, and we have to make assumptions. We don't know:
Whether all recovered files, or just some, contain data
How large these files are, whether they've been overwritten, whether even if they're non-deleted, or what the data is
How old the SSD is, what quality it is, or whether TRIM is implemented in both O/S and SSD
Whether the TRIM queue was overwhelmed and some TRIM commands dropped
Or even if we're talking about Windows and NTFS.
Assuming that TRIM is implemented, the Windows O/S will issue the TRIM ommand and the SSD controller specifies the action to be taken after a TRIM. Most likely It will be DZAT (Deterministic Zeroes After TRIM). Any read of a deleted and TRIMed SSD page will return zeroes.
But we don't know what the SSD controller actually does, nor what settings it has, nor how to see those settings. So we guess.
If I run Recuva on my cheapo SSD and then look at the header info all the deleted files contain zeroes (except for the reasons outlined in my previous post).
59 minutes ago, Augeas said:<div class="ipsQuote_contents ipsClearfix" data-gramm="false"> <p> So we guess. </p> </div>
Personally I think it's pretty amazing how good those guesses can get sometimes, when there is little actual data to go on.
You see it on most help fora.
Just wanted to update that using https://www.irfanview.com/ .the JPGs are still not viewable and I gave up , I guess its impossible to recover on SSD (with trim enabled etc)
Thanks for everyone's suggestions and help, really appreciated.
Thread can be closed.