File names are not accurate

[Blair]

When I ran Recuva on my external back-up drive, it found lots of files, most with "green" excellent rankings. However, when I save them to my computer, none of them open properly. By chance I clicked on one file, supposedly a .ppt file, that gave a preview picture of a totally unrelated .jpg file. A little exploration found several more examples of different files that turned out to be .jpg pictures unrelated to the apparent file name / type.

 

When I recover the ".jpg" files, I simply change the file extension to .jpg and they open fine in a picture viewer. I then have to save them again as .jpg pictures or they will appear to be the size of the incorrect file name. For example, an apparently 10 MB video file was really a 156 kB jpg. I find it odd that during recovery, it appears to be writing data for a long time (enough for 10 MB), when the only data seems to be the one smallish picture file.

 

This is pretty frustrating as it leads me to believe the files are there and available for recovery, but I would have to try them all randomly to find the right ones. Any ideas that could straighten this out?

 

Thanks.

[Augeas]

I guess it's due to the fact that Recuva is looking at free space on the disk that is available for any other file to use, and in some cases several files to use, be deleted and used again. So whilst in normal scan the file info is taken from the MFT record, the cluster(s) it's pointing to may well have been overwritten one or more times. In your example you would be recovering 10 mb of data, but the first 156k has been overwritten by a jpg, which is what you're seeing.

[redhawk]

Excellent doesn't mean 100% correct it an indication that clusters belonging to deleted files are not in use and thus have a higher change for successful recovery.

 

Richard S.

[Blair]

Thanks Augeas. Your reply was prompt and enlightening. I really like your product and I have used it successfully in the past.

 

If I understand correctly, you are saying that the MFT record is telling the program that a file is located in particular location, and nothing is written over it. But in reality something has been written over it, but the MFT record doesn't know about it. This also means that most of the recovered files are just nonsense strings of data from bits of various files, and none of them are likely to be readable by any program.

 

I think that is the "what", but I don't understand the "why". Why doesn't the MFT recognize the files have been overwritten? Will it help to do a "deep scan" or will that have the same problem?

 

In a separate issue, the reason I am trying to recover files off the backup drive is that the files on the primary hard drive are encrypted. Recuva sees them and says they are "excellent", but fails to recover them because they were encrypted. I'm not sure why it can't bring back the data file anyway. My computer should be able to read the encryption once the file is restored.

 

Thanks again for your insights. Very nice Forum.

[Augeas]

When a file is deleted its record in the MFT is flagged as deleted, and the file won't be shown or be accessible in Explorer or other applications. The file data, name, length, where it is on disk, etc. remains in the MFT record. The disk clusters the file occupied are flagged as free space in the cluster map. These clusters can be used by new file allocations.

 

Recuva in normal mode reads the deleted records from the MFT and can retrieve the clusters the record originally pointed to on the disk. However what the data actually is in these clusters can't be guaranteed. Sometimes it's the deleted file, sometimes not. Sometimes it's a live file that's using the deleted file's clusters.

 

Records in the MFT for deleted files are never removed, just flagged as deleted. They can be used for subsequent file allocations, when of course all the file data is updated.

 

A deep scan will look at every free cluster on the disk and try to determine whether it holds data in a recognisable format. If so it will go in the list and can be recovered. I guess this is more 'accurate' than the normal scan, as the actual data is being interrogated. Deep scan can be handy at times but can take forever to run.

 

I don't know much about encryption so I can't comment there.