Undelete big files

I accidentally deleted folder which contained several big files (7-8 GB size each) along with some smaller files (~1 GB size each). The problem was that when I tried to recover big files using various file recovery tools, all of them showed that the sizes of those big files were zero bytes. However I could recover smaller files perfectly. I guess the problem is not with file recovery tools, but maybe with NTFS file system or something, that if you delete huge files, their size turns to zero bytes. I even experimented on another computer with deleting big files (without sending them to Recycle Bin) and got the same results. I couldn't find any information on this issue on Internet, could anybody suggest is there any way to recover those files?

My system specs:
Windows 2000 SP4
Files system: NTFS5
HDD: 160 GB



Edited by Petras - 26 July 2007 at 7:58am

jawz101,

Thank you for your reply. Those files were on external 160GB hard drive, connected through USB. I accidentally deleted almost 100GB of data. Among it there were 6 files of 7-8 GB size. Those files were archives. I instantly realized what happened and no more writing activity to this disk was conducted. I ran several file recovery utilities and all of them showed that these big files are now only 0 byte size. I asked for help also in other forums and contacted some authors of different recovery tools. Most valuable response I received from Back2Life creator Alex Mokrov (thank you, Alex!). Here is what he wrote to me:

"yes, you are right, there's an issue with NTFS and huge files. Well, one more detail - this happens on fragmented NTFS drive. To store a file, NTFS uses MFT records (MasterFileTable). Usually one MFT record is enough, but when file is huge and fragmentation is heavy, several MFT records are used. But somehow Microsoft at erasing files clears all subsequent MFT records, except the first one. This fact has no logical explanation, but it is a fact. That's why when erased file was described by one MFT record, it is recoverable. Otherwise, undelete software can only show a file name...".

I've read a little about how big files are stored on NTFS drives. Here is what I found on pcguide: "If a file is so large that there isn't even room in the MFT record for the list of pointers in the data attribute, [...] the list of data attribute pointers is itself made non-resident. Such a file will have no data attribute in its main MFT record; instead, a pointer is placed in the main MFT record to a second MFT record that contains the data attribute's list of pointers to data runs."

So it seems that if erasing files deletes all subsequent MFT records there is not much to do other than admit that those files are lost. If it deletes only the pointer to those other MFT records which contain pointers to data runs, then maybe there is a hope to find those orphaned MFT records. Unfortunately I didn't find any information on Internet how the process of erasing files acts in this situation. Maybe somebody has any suggestion about it or maybe where to look for more information about this issue. Thank you in advance.


Edited by Petras - 30 July 2007 at 11:50pm

Well, I manage to completely recover 3 out of those 6 huge files. I was lucky, those 3 file were not fragmented. Unfortunately other 3 were fragmented, so I got only the first fragments of them.

But I also conducted a little experiment on what happens when huge files are deleted, and I would like to share here with my findings. Unfortunately here are lots of technical information which may be hard to understand. Much of the information about NTFS, MFT, file records, attributes, etc., I found on Linux NTFS Project page.
So, I had 2 big files 7-8 GB size. Both of them were fragmented, but one of them (let's call it A) had all data runs pointers (to clusters which contains file data) inside its file record in MFT. Another one (B) had so many data runs, so it had to use $ATTRIBUTE_LIST attribute and made $DATA attribute with data runs external and put them in several other MFT records. I saved file records and records with external attributes into separate files so I could use them later in comparisons.
Tools used: R-Studio DEMO, RunTime DiskExplorer for NTFS, WinHex.

Then I deleted those big files and started to analyze. So:
1. Both files for different file recovery tools appears to be 0 byte size.
2. List of attributes are preserved in file records. So $ATTRIBUTE_LIST attribute in B file record remained as well as $DATA attribute in A file record. $DATA attribute in the first external record of B file record is preserved with reduced size. In subsequent external records $DATA attribute is missing - its ID (0x80) is overwritten with $END (0xFFFFFF).
3. $ATTRIBUTE_LIST size is reduced, now it holds only the pointer to the first record of external $DATA attribute. Other pointers are overwritten with subsequent record attributes (like $FILE_NAME and $VOLUME_VERSION), which are shifted according to the new size of $ATTRIBUTE_LIST.
4. External attributes on other file records still point to the base file record of the file B.
5. $DATA attribute (no matter whether it is external or not) size reduced to the size of its header plus 8 bytes (these 8 bytes contained pointer to the first data run).  So it does not include anymore attribute body part which contains data runs. That's why the size is 0 bytes. (There are also "Allocated Size" and "Real size" parameters in header, which also indicate the 0 byte size).
6. While data runs pointers are mostly preserved in file records, some pointers are corrupted. Especially the first data run pointer is always corrupted with some unknown data. So the only way to locate the beginning of the file is by it's signature. That's how I've found them.

So what to do if your precious file is deleted and appears as 0 byte size:
1. Since the pointer to the beginning of the file is corrupted, the only way to locate your file is by its signature. A good place to find out the signatures of the most known files is here.
2. If your file was not fragmented, you're lucky. You only need to know the file size.
3. If your file was fragmented, the  most you can do, is to try to reconstruct the file from data run pointers which were not corrupted.
4. If your file was very fragmented and its file record has external attributes located in additional file records, you can identify them by parameter "Base file MFT" in record header. It contains a pointer to the base file record.

I hope these findings will be useful to somebody. But it is still a mystery to me why Windows treats differently small and huge files and deletes them differently. I couldn't find any information about this issue. Maybe someone could clarify this?

Oh i had the same problem,i recovered all that using a small trial free tool available at http://pathtoodeep.com ,it will help you to recover all