Recuva gives conflicting information about a 1.2 GB file I already secure deleted

[Andavari]

Recuva gives conflicting information about a 1.2 GB file I already secure deleted with a different overwriting program.

After scanning it states this on the right-hand side in the Comment area:
File's data could not be found on the disk

After attempting to secure delete the file with one-pass it then states this in the pop-up window:
Not overwritten - File is resident in the MFT

Also how could it state the 1.2 GB file is resident in the MFT, when Windows Disk Defragmenter states the MFT is the same size as it was before which is 76 MB, and after rebooting it still reads as 76 MB.

[Augeas]

As we don't know what the 'different overwriting program' was (and don't tell me, I will know nothing about it) we'll have to assume that the process was similar to CC's, i.e. that the file is edited to contain only zeroes then it is deleted. It's a bit of a misnomer, there is no such thing as secure deletion, it's an edit then delete.

The MFT record for a file contains a header then a string of variable length attributes, beginning with $Standard Info, then $File Name. etc. Attribute $Data holds the addresses of each data fragment as a cluster start number and cluster count. If there are many fragments then the addresses can't all fit into the 1024 byte record, so a new MFT record is created containing just the $Data attribute, and the main MFT record points to that. (These cluster addresses are often held as negative little-endian, which is not to be trifled with, but I digress.)

When a file with a large number of fragments (and multiple MFT records) is deleted then NTFS overwrites the cluster addresses in the extension records and overwrites the link to the extension records in the main MFT record. I've no idea why NTFS does this, it probably values MFT integrity over assistance in recovering deleted files.

So you are left with an MFT record (which Recuva finds) with a file size of 1.2 gb in the $File Name attribute and no accessible data clusters. I have seen Recuva issuing the data not on disk message in similar cases. I haven't tried to overwrite one of these records but I would not be surprised if Recuva says that the data is resident in the record (which as sure as grass is green it isn't), as there are no data clusters to locate and overwrite.

I am coming (OK, I'm already there) to the conclusion that your 1.2 gb file was in many fragments and the above scenario applied. It's not much to worry about (but why were you tryimg to recover a securely deleted file?). If the file had been normal deleted then a wipe free space would be required to overwrite it.

[Andavari]

I wasn't trying to recover the securely deleted 1.2 GB file, I was just testing to make sure the freeware drag 'n' drop unsaid secure deletion program I used could actually securely delete a file properly because there are some secure deletion programs that seemingly don't work as intended, i.e. they fail.

The testing is what had me wondering why Recuva was stating conflicting and confusing information since I've never experienced it giving results like that before.