Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I want to recover an overwritten file on a NTFS partition.

Let's say I have file named A in a directory.

I made another file but I saved this new file with the same name, "A". Will the new file stored on the existing physical location of A, (meaning that original contents of A will never be able to be recovered), or will the new file probably occupies another physical location on the disk (meaning that the original contents may probably still be recoverable)?

share|improve this question
1  
Even if it didn't overwrite every single sector, it's going to be near impossible to get the data back. When you overwrite it, you've broken the "chain" leading you through each sector (i.e. the first sector points to the next, and the next, etc.). Those data may be sitting out on the hard drive somewhere, but you'd have to search every single "free" sector on your hard drive to try to recover it. And even if you could find every sector, what order do they go in? I hope you had a backup. –  Michael Todd Oct 27 '09 at 3:49
add comment

3 Answers

up vote 3 down vote accepted

It depends on the application. Word, for example, writes a new file then deletes the old one so it will not overwrite it and it can be recovered. Another app might rewrite the file in place and then truncate to the correct size, in which case you will lose all the data.

if the file is truncated first (setting physical size, not logical size) and then rewritten, I'm not sure what would happen w/o testing it. If the old file is deleted then a new one created with the same name, I think it's a matter of chance.

If the file is small enough to fit in the MFT entry for the file (~4k?, I don't recall), you're more likely to have the data overwritten.

share|improve this answer
add comment

This credible sounding newsgroup post, as well as Tony Lee's answer indicate that for most applications a "save as" ovewrite is the same as a delete, followed by a create-new as far as the file system is concerned. I can second that generalization because as as a programmer, it makes sense. If I were implementing "Save as" feature there is no reason to use a file-open for re-write API call, as this is code path would only be used in the rare case of an overwrite. A programmer is much more likely to use the create-new file call with a quick fileDelete call in the rare case it is necessary.

That said, there is no sure way to know how the progammer of the overwriting app chose to deal with the existing file, unless you can ask them, or trace the app's file system behavior with a tool like FileMon or Process Monitor.

On average, I'd guess that you are only slightly less likely to to recover a file that was "overwriten" by an application compared to any other file that was deleted followed by writes to the disk.

Needless to say NTFS undeletes are not a very reliable recovery strategy. If this is likely to happen again, Look into some sort of version control system to supplement your daily back-up strategy. Unfortunately automatic file versioning that used to be a standard feature in some Operating Systems like VMS and Netware is no longer a common feature in the mainstream market.

share|improve this answer
add comment

It may or may not there is no way of knowing. NTFS will put write files wherever it thinks best there is no guarantee where it will place a file. If you want to recover a file do it as soon as possible, the longer you wait the more chance there will be that the old file will be overwritten.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.