Data Recovery and Disk Utilities Forum @R-TT

@Data-Medics :
Why would the outcome be any different if unchecking the other files ?
And how could Thunderbird possibly find lost e-mails in an Inbox database which was shrunk from 97GB to 4KB ?

@John2019 :
[quote]I really can not understand how writing a 0KB file over a 97GB one can destroy the entire structure since the data should be still in the same location.[/quote]
It most likely overwrote the MFT record, wiping the allocation information found in the original MFT record. If the original file was massively fragmented it had secondary MFT records which may still be intact after the main record was overwritten, but the information about the cluster chain is almost impossible to reconstruct at this point, since each data run in each MFT record is [i]relative[/i] to the one before (it translates as, for instance : 10 clusters starting from cluster 12345 / 20 clusters at cluster +534, which means 12345 + 534 = 12879 / 12 clusters at -1032, which means 12879 - 1032 = 11847... and so on -- since all values except the first one are relative, if one value is missing or corrupted the filesystem loses track of the actual locations of all subsequent clusters belonging to the file) ; so even if for instance the main MFT record is 12345 and it can be guessed that MFT records 12346 to 12385 also pertain to that file, it may still be possible to know the [i]relative[/i] position of the clusters identified in those secondary MFT records, but it's no longer possible to determine where it starts as a huge chunk from the main MFT record is missing.

[quote]I was wondering if r-studio can behave similar to dd under linux and just try to byte copy the whole block since the file might be consecutive.[/quote]
If you know where the file is supposed to begin you can do that easily with any hexadecimal editor, WinHex for instance, define a block starting at the beginning of the 4KB file, go 97GB below and define the end of the block, and copy the block as a new file. But again it's highly unlikely that such a large and constantly updated file was contiguous, so it's highly unlikely that a file extracted with such a rough method would allow to recover a significant amount of the total, if Thunderbird can open it at all.

First, 97GB seems HUGE for an e-mail database. You should sort messages by year and/or category. Second, an e-mail database is not just a blob of “mostly text”, it has a distinct structure, if key components of that structure have been corrupted it may no longer be properly recognized by the software accessing it, Thunderbird in this case. I don't know specifically how robust the file format used by Thunderbird is, but generally speaking, for any type of remotely complex file, if the header has been overwritten it does not sound good. Third, a large database file which is regularly modified will almost certainly be fragmented, possibly massively fragmented (hundreds or thousands of fragments all over the place). In which case the odds of successful recovery by means of raw file carving are very low. Fourth, something as important as an e-mail database should be backed up at least weekly if not daily.

If you were wise enough to do a complete image of the partition where that humongous file was located right after it happened, it may still be possible to do a custom analysis of the MFT records pertaining to that file. It would have been interesting to see what R-Studio displayed in the “Sectors” tab of its hexadecimal analyser. I once [url=https://superuser.com/questions/1267818/rebuild-massively-fragmented-files-with-a-partial-image-and-a-list-of-their-sect]did something very convoluted[/url], using ddrescue, to recover a bunch of massively fragmented files, in a situation where I had made a partial image containing all the sectors occupied by those files (except the unreadable ones), and an incomplete MFT, and a list of those files' clusters, while the drive's condition had declined to the point where it was no longer possible to complete the image in order to get the whole MFT. I had obtained the list of sectors / clusters with Recuva, HD Sentinel and nfi, when the drive was still operational ; R-Studio can display the list of sectors occupied by a file, but, unless it's been added in a recent update, it offers no way of exporting the complete list for further purposes (only one value at a time can be copied with CTRL+C which is not practical at all).

If you check just the damaged file, not the other files, you should get a file saved that is that 97Gb.

If only a small amount of it was overwritten you might then have some success using this method: https://www.easeus.com/file-recovery/restore-deleted-lost-thunderbird-emails.html#4

(Ignore that fact it's on Easeus website, I'm not recommending you try their software, it won't help. But, the directions of how to use Thunderbird to scan for lost emails in the inbox file is good)

Hi Alt,

and thanks for your reply i tried to recover only this file alone with the same result then the recovered file is only 4kb in size. I was wondering if r-studio can behave similar to dd under linux and just try to byte copy the whole block since the file might be consecutive. I really can not understand how writing a 0KB file over a 97GB one can destroy the entire structure since the data should be still in the same location.

How to get some additional ideas.

Thanks

Overwritten files are usually hard to recover.
Try to recover only the overwritten file and check the result.

Hello i'm trying to recover my Email INBOX file from Thunderbird Mail from my Mechanical Hard drive.

System:
ThinkPad T480
HDD: 2TB Western Digital - NTFS
Windows 10
R-Studio 8.12.175721 Personal Edition
File: INBOX

The file was overwritten with an empty file when i did some changes on my email account. Once i realized this i immediately stopped using the Software and started R-studio trying to recover it. R-studio is showing the deleted file but when i try recovery the file is only 4KB not the whole 97GB.
Is there any way to try recovering the whole 97GB file since it should be still in the same location just some parts might be corrupted. Since it's email and mostly text it should not be so critical it there is some file corruption since it should only mean to lose some mails.

I attached some pictures to explain what i mean

Thanks for your help