shax_muzzz
Цитата:
Вычисляется это не сложно. В атрибуте 20 перечислены все атрибуты, кроме самого ATTRIBUTE_LIST. Для каждого атрибута указан номер записи, в которой он расположен (см. Linux NTFS, смещение 10h от начала вариантной части атрибута - Base File Reference). Умножаем номер записи на 2 (размер записи) и имеем виртуальный сектор искомой записи. Если у Вас MFT не фрагментирована, или уже слита в один файл, то виртуальный сектор равен "обычному" (логическому, как можно было бы назвать, аналогично logical cluster number == LCN). Если MFT фрагментирована, естественно, надо пересчитывать с учетом ранлиста, но, как я понял, Вам это не актуально.
Для Вашей записи. Для атрибутов 10 и 30 указана запись 6B9Fh, что совпадает с номером текущей записи, указанном по смещению 2Ch от начала записи. И действительно эти атрибуты мы видим в Вашем дампе. Что касается DATA, то для него использована только одна запись 15D37h, т.е. это сектор 178798 (2BA6Eh) от начала MFT.
Цитата:
Насколько я знаю, если есть расширенные записи, то в них при удалении пишется новый пустой DATA, который затирает начало старого DATA, из-за чего восстановить проблематично (не представляю, как это можно сделать, т.к. подобная фигня, как Вы понимаете, бывает только у сильно фрагментированных). Но чтобы убивались базовые записи, такого не встречал (но у меня опыта мало).
У меня был только один успешный кейс с таким файлом. По какой-то причине MFT была усечена, в результате Чекдиск обкастрировал базовую запись, но по счастливой случайности весь DATA был в двух расширенных записях, а т.к. это было не удаление, то расширенные остались нетронуты (они были за пределами усеченного размера MFT), и файл был востановлен (база The Bat).
Linux NTFS (PDF)
СИИЖТ NTFS (PDF)
Кэрриэ. Анализ ФС (DJVU)
Цитата:
что-то до меня не доходит как вычисляется место хранения дополнительных записей File Record по атрибуту 0х20
Вычисляется это не сложно. В атрибуте 20 перечислены все атрибуты, кроме самого ATTRIBUTE_LIST. Для каждого атрибута указан номер записи, в которой он расположен (см. Linux NTFS, смещение 10h от начала вариантной части атрибута - Base File Reference). Умножаем номер записи на 2 (размер записи) и имеем виртуальный сектор искомой записи. Если у Вас MFT не фрагментирована, или уже слита в один файл, то виртуальный сектор равен "обычному" (логическому, как можно было бы назвать, аналогично logical cluster number == LCN). Если MFT фрагментирована, естественно, надо пересчитывать с учетом ранлиста, но, как я понял, Вам это не актуально.
Для Вашей записи. Для атрибутов 10 и 30 указана запись 6B9Fh, что совпадает с номером текущей записи, указанном по смещению 2Ch от начала записи. И действительно эти атрибуты мы видим в Вашем дампе. Что касается DATA, то для него использована только одна запись 15D37h, т.е. это сектор 178798 (2BA6Eh) от начала MFT.
Цитата:
интересен сам механизм
Насколько я знаю, если есть расширенные записи, то в них при удалении пишется новый пустой DATA, который затирает начало старого DATA, из-за чего восстановить проблематично (не представляю, как это можно сделать, т.к. подобная фигня, как Вы понимаете, бывает только у сильно фрагментированных). Но чтобы убивались базовые записи, такого не встречал (но у меня опыта мало).
У меня был только один успешный кейс с таким файлом. По какой-то причине MFT была усечена, в результате Чекдиск обкастрировал базовую запись, но по счастливой случайности весь DATA был в двух расширенных записях, а т.к. это было не удаление, то расширенные остались нетронуты (они были за пределами усеченного размера MFT), и файл был востановлен (база The Bat).
Linux NTFS (PDF)
СИИЖТ NTFS (PDF)
Кэрриэ. Анализ ФС (DJVU)
(извиняюсь за глумление). Вам надо было записать 8 секторов. 
