Question ST2000DX001 "Corrupt" (overwritten?) master file table.

Dec 18, 2023
2
0
10
In reference to https://forums.tomshardware.com/threads/master-file-table-corrupt-chkdsk-fails.3712756/ :
That thread seems to trail off into a cliff hanger, and I have my own issues that are VERY similar to the OP in that thread. So I followed along until I reached the dead end.
Where I'm at in the process: I have a full scan done. (boy howdy that sucked up some time)
"If you highlight $Volume 01 and select Open Volume" is also grayed out for me. So I followed the offset, in my case I don't exactly have a $Volume 01 so I tried to follow each what I assume is a (volume's last sector+1+786432x8) (following the pattern in the previous thread) to look for a FILE0 signature.
I get some gibberish
at the most likely point. And nothing nearby worth mentioning either.
It's worth noting one of my blocks starts with "bootmgr" except that I don't use this harddrive for booting, and to the best of my knowledge I never attempted to install an operating system on it. This is my backup data drive and I'm very familiar with it and it's distinctly different from the NVME drive I use to boot my OSes
It also states, in the data, nearby "
An operating system wasn't found. Try disconnecting any drives that don't
contain an operating system." This is in the drive itself like that. It's not a popup, this is the data.

Additionally my files are "recoverable" to a degree, after easeus tried to rip me off by saying it was "Free" and then turning around and asking for payment after recovering a measly 3000 files I began looking at DIY options, so here I am. Should I just make a new thread? Because the selected "solution" here doesn't feel like a solution and there doesn't seem to be any resolution.
Do you think it would be possible to manually recreate the headers that define this drive for storage? I'm sure I'd lose a few files at the beginning of the drive, but this is negligible to the TB and 15 years of history that I have backed up on this device. I could theoretically manually go through each individual file and recover everything, but..like I said, 2TB isn't a "by hand" process. This really seems very easily solvable, it REALLY feels as though an operating system installation was attempted, somehow, and that started to wipe the drive, but then it got caught on some kind of error (thankfully) and ended prematurely. I assume a write of that type would be sequential enough that I should be able to sequentially write in the same data that a storage drive would be using with NTFS. Correct me if I'm wrong.
It's also worth mentioning, and this is going to sound really strange, I recently installed a virtual windows image directly to this harddrive. But...this isn't the harddrive I was aiming for. I was aiming for my NVME, and I ended up on this drive. Thankfully this drive was already empty, but I didn't aim for it. Could this be related to the CAUSE behind my master file record being overwritten/corrupted? AND the storage NVME drive I use for games has been in a constant fluctuation of problems ever since I started using steam on manjaro linux.

Shoutout to @fzabkar as they seem to know this deep dive storage junk a lot better than I ever will.

P.S. I'm sorry that I've been building computers for 16 years and never made an account here.
 
Last edited by a moderator:
Dec 18, 2023
2
0
10
So this was how I ended up solving my issue using TestDisk.

Thanks to mdd1963 for that link.
First I went about analyzing my drive and trying to determine this that and the other thing about the partitions etc etc. Waste of time.
I wasted hours of my life.

To solve MY issue I ended up not using the log (optional) selected my drive, selected my partition table type, [Boot] -> Repair MFT alone didn't work, but Repair MFT and Repair Boot Sector together worked.

Unfortunately this is a pretty generalized solution, but anyone in a situation like mine, where an OS clearly tried to overwrite a data drive, this SHOULD work for you.
Shoutout to Christophe Grenier for the tool. What a legend.