I have a 2TB Seagate ST2000DM001 HDD with one NTFS partition. I hadn't used it in months, when I plugged it again this partition had inexplicably become inaccessible : the volume's letter appears in Windows Explorer, but the partition's size is no longer recognized, there's an error if I try to open it. It appears as “RAW” in the storage manager. CHKDSK gives up analyzing it right away, with an error message saying that it's unable to determine the version and the state of the volume.
Yet, if I open that drive with R-Studio, the partition appears right away with its correct size (no scanning is even required), I can open it and access all the files that were there the last time I used it normally, with the whole directory tree, and the files' contents seem 100% correct as far as I can see. Likewise, if I open the whole drive with WinHex, it correctly recognizes the partition, and displays the files & folders with their correct contents. I also tested 2 defragmentation softwares (in analysis mode only) : MyDefrag can list the partition's contents and provides valid information for each block hovered over with the mouse pointer (file name, size, LBA...) ; but Defraggler can't. I also opened it with DMDE : like R-Studio, it can recognize the partition's contents instantly ; it also displays a red warning regarding MFT records 1, 2, 3 ; these typically correspond to : $MFTMirr, $LogFile and $Volume, three important system files, which are indeed missing in the “$MetaData” directory. If I go back to R-Studio, I can see that those files are also missing in the “Metafiles” directory. If I examine the begining of the MFT with WinHex, I can see that MFT record 0 is fine (it points to the MFT itself), but then MFT records 1, 2 and 3 are corrupted, they are filled with “FF” (hex) / “ÿ” (ASCII). And the strange thing is that the MFT mirror (which I can still locate with WinHex using an old volume snapshot, made before the problem appeared, and its location is also indicated by R-Studio in its partition properties pannel, apparently both the MFT and MFTMirr have their LBA written in the boot sector) has the exact same corruption pattern : the first record is fine, then the next three are filled with “FF”.
Now, my guess is that the partition is inaccessible because those three MFT records are missing, thus the corresponding files can't be found. And CHKDSK must require at least those files to operate properly. How could that happen ? How could both the MFT and its mirror (with is actually only a copy of the first 4 records, but in this particular case it should have been enough to fix the issue since the 3 corrupted records are among those 4) end up corrupted at the same time ?
And how could I fix / recreate those missing MFT records, so as to fix the partition “in place”, instead of extracting all the files (which I already did as a safety measure), re-formatting the partition, and transfering them back ? I could copy the valid records from another partition, and change the variable values, knowing the template, but so far I could only identify the timestamps (which I can copy from other system files on the same partition, as they're all created at the exact same time), I can't yet locate the fields indicating the size of the clusters location. I also found out that $Volume, which is a resident file (located entirely in the MFT), contains the partition's unique identificator, which might be the most problematic hurdle here : should it necessarily be the same as before for the partition to be properly recognized, and if so, is it stored somewhere in the system, or can it be randomly chosen, and if so, is there a particular pattern it has to conform to ? The information about the basic structure of MFT records seems to be scarce, or very hard to find among thousands of pages of meandering forum threads or articles with a too broad scope to be of any use in a case like this.
I described the issue with more details on HDDGuru, but didn't have a relevant answer to the question “how can I fix it?” (regular contributors there are highly knowledgeable when it comes to hardware / firmware failures, but for that kind of logical failures they seem to give up rather quickly).