Итак, мне удалось решить проблему самостоятельно. Я провел некоторое исследование о структуре записей 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.