Раздел NTFS больше не доступен, 3 записи MFT повреждены, способ их исправить?

Итак, мне удалось решить проблему самостоятельно. Я провел некоторое исследование о структуре записей MFT в целом и об особой структуре 3 поврежденных записей, которые мне пришлось воссоздать (подробности см. В связанном ветке HDDGuru), изучая их на нескольких допустимых разделах. Затем я скопировал их из действительного раздела во временный файл в WinHex, изменил некоторые значения ключей, которые отличались от одного раздела к другому, затем скопировал файл размером 3072 байта непосредственно в раздел, запустил CHKDSK, который можно продолжить и (после сообщалось, что в томе не было ошибок, и теперь раздел снова доступен. Я до сих пор не знаю, как это случилось, но это исправлено!

Значения, которые я должен был изменить:
- метки времени: все системные файлы имеют одинаковые метки времени, поэтому я просто скопировал поля меток времени из первой записи MFT (которая указывает на сам MFT) в поврежденном разделе;
- в каждой записи есть 1-байтовое поле с именем "fixup" в DMDE, присутствующее в трех разных местах в каждой, что, как мне кто-то объяснил в ветке HDDGuru, является просто "проверкой, чтобы убедиться, что запись действительна и не повреждена" ”И может быть установлено любое значение, при условии, что оно одинаково во всех трех экземплярах этого поля;
- первый кластерный LBA для записи $LogFile (я знал, где она находится, благодаря старому снимку тома WinHex, в противном случае мне пришлось бы искать файл на основе его заголовка, чтобы получить это значение; его размер по умолчанию составляет точно 64 МБ, или 67108864 байта, то же самое на всех разделах, которые я исследовал);
- для записи $Volume (которая также содержит фактический файл $Volume, поскольку этот файл является "резидентным", то есть полностью содержится в его записи MFT), мне пришлось найти исходный 16-байтовый идентификатор (или "идентификатор объекта") том, который был самой сложной частью: после некоторых неудачных попыток я обнаружил это значение в файле "tracking.log", в каталоге "System Volume Information" (сначала я проверил его на предмет допустимого раздела, значение которого соответствует который появился в $Volume, поэтому я скопировал соответствующее поле из "tracking.log" на поврежденном разделе и вставил его в поле идентификатора тома в $Volume);
- также в $Volume я изменил имя тома, чтобы оно имело то же имя, что и раньше, но в этом не было необходимости, я мог бы пропустить имя из другого раздела и изменить его позже в свойствах тома, как только он снова станет доступен. (на самом деле я использовал небольшую хитрость здесь: я скопировал конец записи $Volume из раздела с именем "TEMP", затем вместо того, чтобы изменить это имя на "Stockage", как этот раздел вызывался ранее, я поставил "Stoc", чтобы оно имело одинаковое количество символов, чтобы избежать непредвиденного смещения и чтобы убедиться, что значение "используемого размера" будет соответствовать, так как я еще не до конца понимаю структуру записи);
- поскольку я изменил имя тома, длина фактически используемой записи файла была другой, поэтому мне пришлось изменить поле, соответствующее "используемому размеру", чтобы отразить это и сохранить согласованность (я поставил тот же "использованный размер", что и один из раздела под названием "ТЕМП");
- было другое значение, которое было другим, в начале записи $Volume, называемой "LSNlo" в DMDE: на основании моего исследования "LSN" означает "порядковый номер $LogFile", и это ссылка на последнее записанное изменение в $LogFile для определенной записи файла в $MFT это не критично для согласованности, и в любом случае я обнаружил, что ограниченный по размеру $LogFile регулярно "удаляет" старые записи, поэтому, поскольку я не использовал это диск в месяцах, запись, соответствующая значению, которое было там до его очистки, была удалена, поэтому я просто поставил нули в этом поле.

@DrMoishe Pippik: В качестве меры безопасности я извлек все содержимое с помощью R-Studio на другой диск, прежде чем пытаться исправить это на месте. Я также сделал частичное резервное копирование первых 5 ГБ (этого достаточно, чтобы вместить все соответствующие структуры файловой системы - хотя следует подчеркнуть, что не всегда достаточно получить весь MFT, я научился этому нелегко!). Я не пытался получить доступ к диску на другом компьютере, но я не вижу, как он мог бы отличаться (в любом случае, в системе Windows - возможно, он все равно был бы распознан и доступен в системе Linux), поскольку эти три Записи MFT оказались эффективно уничтоженными в WinHex, и проблема сохранилась после перезагрузки.

@cybernard: я попробовал TestDisk, это была одна из моих первых идей после проверки состояния SMART (что было и остается в порядке): он нашел раздел и мог перечислить файлы (как и другие программы, о которых я упоминал), но он не мог решить проблему, поскольку все, что он может сделать в случае повреждения MFT, это восстановить первые 4 записи, скопировав их из $MFTMirr, но здесь эти три поврежденные записи также были повреждены в $MFTMirr, точно таким же образом.,

@Andrea Lazzarotto: Согласно моим наблюдениям, $MFTMirr всегда находится в секторе 16, то есть в самом начале тома, перед фактическим $MFT, который по умолчанию составляет около 3 ГБ. CHKDSK, вероятно, не работал, потому что $MFTMirr также был поврежден, и поэтому он не мог получить доступ к явно важному файлу $Volume, который также был стерт, поскольку он является частью его записи MFT.