Moderators Andavari Posted March 19, 2018 Moderators Share Posted March 19, 2018 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. Link to comment Share on other sites More sharing options...
Moderators Augeas Posted March 20, 2018 Moderators Share Posted March 20, 2018 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. Link to comment Share on other sites More sharing options...
Moderators Andavari Posted March 20, 2018 Author Moderators Share Posted March 20, 2018 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. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now