Jump to content
CCleaner Community Forums
Sign in to follow this  
Fractalogic

How is "unrecoverable" better than "poor"?

Recommended Posts

Hello!

 

I'm looking at a microSD card here, and I can't help but wonder what the different file "states" as seen in Recuva actually mean. I have one JPG picture file that's "unrecoverable" and another that's "poor". But after I recover them both, the file that was supposedly "unrecoverable" is 100% OK from what I can tell by naked eye, while the file that was rated "poor" is missing the bottom half of the picture.

 

What are the criteria for the various states to appear? Unrecoverable, Poor, Very poor, and Excellent? How can "unrecoverable" be better than "poor"? I would imagine that unrecoverable means that the file can't be recovered, at all. While poor or very poor means that the file is partly or completely corrupted, and that only parts of it can be recovered. Maybe I'm looking at this upside down?... could this be a bug?

post-55142-0-13608900-1454434815_thumb.png

post-55142-0-47933800-1454434821_thumb.png

post-55142-0-61819200-1454434830_thumb.png

post-55142-0-80749100-1454434835_thumb.png

Share this post


Link to post
Share on other sites

Excellent - no file data clusters have been overwritten by another live file

Poor - some clusters have been overwritten by another live file

Very Poor - a lot of clusters have been overwritten by another live file

Unrecoverable - all the clusters have been overwritten by another live file

 

When you recovered the unrecoverable file you, or rather Recuva, copied the data clusters that used to contain the deleted file. As those clusters have been reused by a live file, you're actually recovering that live file. The original file has long gone.

Share this post


Link to post
Share on other sites

A cluster is the same thing as allocation unit in Windows, right? If so, then this one is 32K.

 

Is an "unrecoverable" file actually recoverable? If it is, then shouldn't the recovered cluster data be the data of the new file? And not the data of the overwritten file?

 

I don't see how this "unrecoverable" JPG file can have been overwritten by another file, according to Recuva, an MP4 file. Because there were no new file write operations done after the JPG file was deleted. The suspected MP4 that supposedly overwrote the data clusters of the JPG file coexisted with the JPG file and was deleted together with the JPG file.

 

See why I don't think the data clusters of JPG were overwritten by MP4?

 

Unrecoverable:

20151103_115540.jpg

 

Overwritten by:

20160104_190343.mp4

 

You can tell the date of creation of each file by their names. However, they were both deleted today, 2 Feb 2016, at the same time. No new files have been written to the SD card.

 

So how is this possible then? It's not! Please prove me wrong. But I believe this is a false positive. This file is in fact Excellent! I believe... I don't have the original to compare to, obviously. But I am pretty confident that this is it, it's in its original form, and Recuva recovered it. But it falsely states that it's "unrecoverable". It's close to impossible that any bit of the data cluster has been overwritten.

 

Thank you for the explanation of the different states. But I don't think these can be trusted.

post-55142-0-25694700-1454443277_thumb.png

post-55142-0-72958500-1454444078_thumb.png

Share this post


Link to post
Share on other sites
Fractalogic, on 02 Feb 2016 - 8:22 PM, said:

A cluster is the same thing as allocation unit in Windows, right? If so, then this one is 32K.

 

Clusters is what Windows calls them, and yours are indeed 32k.

 

Fractalogic, on 02 Feb 2016 - 8:22 PM, said:

Is an "unrecoverable" file actually recoverable? If it is, then shouldn't the recovered cluster data be the data of the new file? And not the data of the overwritten file?

 

Recuva will copy the contents of whatever clusters are associated with the deleted file, whether that content is of any use to you or not. So although the original file may be 'unrecoverable' in the fact that Recuva can determine that the data has been overwritten, the clusters will still be retrieved.

 

Fractalogic, on 02 Feb 2016 - 8:22 PM, said:

I don't see how this "unrecoverable" JPG file can have been overwritten by another file, according to Recuva, an MP4 file. Because there were no new file write operations done after the JPG file was deleted. The suspected MP4 that supposedly overwrote the data clusters of the JPG file coexisted with the JPG file and was deleted together with the JPG file.

 

See why I don't think the data clusters of JPG were overwritten by MP4?

 

Unrecoverable:

20151103_115540.jpg

 

Overwritten by:

20160104_190343.mp4

 

You can tell the date of creation of each file by their names. However, they were both deleted today, 2 Feb 2016, at the same time. No new files have been written to the SD card.

 

So how is this possible then? It's not! Please prove me wrong. But I believe this is a false positive. This file is in fact Excellent! I believe... I don't have the original to compare to, obviously. But I am pretty confident that this is it, it's in its original form, and Recuva recovered it. But it falsely states that it's "unrecoverable". It's close to impossible that any bit of the data cluster has been overwritten.

 

FAT32 - your file system - sets the two high-order bytes of the file's first cluster address to zero on file deletion. When Recuva extracts the first cluster address it is actually pointing to the wrong place. So a file that has been deleted can quite easily appear to have been overwritten by one or more files. The mp4 file that is apparently overwriting the jpg may itself have zeroed high-order bytes in its address. With 32k clusters the low-order two bytes will only have two possible values, so many deleted files may point to these two addresses.

 

Bear in mind that I (and everyone else here) don't know exactly what Recuva does in detail.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...