Jump to content
CCleaner Community Forums

Recuva not recovering a simple file.


Recommended Posts

As a test I created a document in Notepad. The only words in it were one - 'Test'. I then saved the document to a USB and ran Recuva immediately not using the deep scan. The response was - Unrecoverable - ' This file is overwritten with "E:\BACKUP\x64\sources\boot.wim". I've tried the same test before using the deep scan. The result was the same. Any ideas?

I'm running W7 Home on a Desktop.

Link to post
Share on other sites
15 hours ago, Augeas said:

Is the file type FAT32?

Hi, Yes it is on the USB. On the hard drive it's NTFS.  The coding is ANSI if that helps. I've also tried saving it to the hard drive too but the result is the same.

Link to post
Share on other sites
  • Moderators

FAT32 is a beefed-up version of FAT16. However it needs four bytes to hold the first cluster number (in the FAT tables) instead of two, so it uses two additional bytes from elsewhere (the actual address of the start of the file is held in two separate halves). When a file is deleted the additional two bytes of the address, the high end, are wiped by the file system for some reason, and as a result the address of the file is corrupted. This is why you get the overwritten file message, Recuva is looking in the wrong place. It isn't possible to find the right place, except by guessing.

A deep scan looks for clusters with a recognisable file signature, so can be useful in cases such as this. However a text file has no file signature, so is not identified by Recuva.

It may be possible to find this file with a hex editor, but as it's only a test it isn't worth bothering.

Link to post
Share on other sites
27 minutes ago, Augeas said:

FAT32 is a beefed-up version of FAT16. However it needs four bytes to hold the first cluster number (in the FAT tables) instead of two, so it uses two additional bytes from elsewhere (the actual address of the start of the file is held in two separate halves). When a file is deleted the additional two bytes of the address, the high end, are wiped by the file system for some reason, and as a result the address of the file is corrupted. This is why you get the overwritten file message, Recuva is looking in the wrong place. It isn't possible to find the right place, except by guessing.

A deep scan looks for clusters with a recognisable file signature, so can be useful in cases such as this. However a text file has no file signature, so is not identified by Recuva.

It may be possible to find this file with a hex editor, but as it's only a test it isn't worth bothering.

Thanks for the info. I see what you mean.

I just tried deleting an Excel file ran Recuva and it found the file but was confused about what type of file it was. It recovered it a a Word file??

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...