Recuva not recovering a simple file.

[Ukdodger]

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.

[Augeas]

Is the file type FAT32?

[Ukdodger]

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.

[Augeas]

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.

[Ukdodger]

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??