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

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

значения, которые я должен был изменить были:

- временные метки: все системные файлы имеют одинаковые временные метки, поэтому я просто скопировал поля временных меток из первой записи MFT (которая указывает на саму MFT) на поврежденный раздел ;

– есть 1 байт поля на каждую запись под названием "исправление" в DMDE, присутствует в трех различных точках в каждом из, которых, как кто-то объяснил мне, на HDDGuru нить это просто "проверить, чтобы убедиться, что запись действительна и не повредить" и может быть установлен на любое значение, так долго, как это же во всех трех случаях в этой области ;

- первый кластер LBA для записи $ LogFile (я знал, где он находится, благодаря старому снимку Тома WinHex, иначе я бы пришлось искать файл на основе его заголовка, чтобы получить это значение ; его размер по умолчанию составляет ровно 64 Мб, или 67108864 байт, то же самое на всех разделах я рассмотрел);

– для записи $Volume (которая также содержит фактический файл $Volume, так как этот файл является "резидентным", т. е. полностью содержится в его записи MFT), мне пришлось найти исходный идентификатор 16 байтов (или "идентификатор объекта") Тома, который был самой сложной частью : после некоторых неудачных попыток я нашел это значение внутри Тома. "следящий.log "file, в каталоге" System Volume Information " (я сначала проверил его на допустимый раздел, значение соответствовало тому, которое появилось в $Volume, поэтому я скопировал соответствующее поле из "tracking.log " на поврежденном разделе и вставил его в поле id Тома в $Volume);

– кроме того, в $Volume я изменил имя Тома, чтобы иметь то же имя, что и раньше, но это было не обязательно, я мог бы позволить имя из другого раздела и изменил его позже в томе свойства после того, как он был доступным снова (на самом деле я использовал маленькую хитрость тут : я скопировал конце $, что является рекордным объемом с раздела под названием "темп", а затем, вместо того, чтобы поменять имя с "запасом" как раздел назывался раньше, я поставил "в наличии", так что оно не будет иметь одинаковое количество символов, во избежание неожиданного смещения, и быть уверенным, что "размер" значение будет соответствовать, поскольку я пока не до конца понимаю структуру записи) ;

- поскольку я изменил имя Тома, длина фактически используемой записи файла была другой, поэтому мне пришлось изменить поле, соответствующее "используемому размеру", чтобы отразить это и сохранить согласованность (я поставил тот же" используемый размер", что и в разделе" TEMP");

– было другое значение, которое было другим, в начале записи $ Volume, называемой" LSNlo "в DMDE : на основе моего исследования" LSN "означает" порядковый номер $ LogFile", и это ссылка на последние изменения зафиксированы в $журнале по поводу данного файла запись в $MFT, это не так важно для консистенции, и вообще я узнал, что $файл журнала ограничен в размере его регулярно "чистки" старых записей, так как я не использовал этот диск уже несколько месяцев, запись соответствующего значения, которое было до того, как она была уничтожена была удалена, так что я просто поставил нули в этой области.

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

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

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