Рисунок 3. DiskExplorer отображает главную файловую запись в естественном виде

Файловые записи (FILE Record)

Благодаря наличию Disk Explorer от Runtime Software с файловыми записями практически никогда не приходится работать вручную, тем не менее знание их структуры нам не помешает.

Структурно файловая запись состоит из заголовка (header) и одного или нескольких атрибутов (attribute) произвольной длины, завершаемых маркером конца (end marker) – четырехбайтовым шестнадцатеричным значением FFFFFFFFh (см. листинг 1). Несмотря на то что количество и длина атрибутов меняется от одной файловой записи к другой, размер самой структуры FILE Record строго фиксирован и в большинстве случаев равен 1 Кбайту (это значение хранится в $boot-файле, не путать с boot-сектором!). Причем первый байт файловой записи всегда совпадает с началом сектора.

Если реальная длина атрибутов меньше размеров файловой записи, ее хвост просто не используется. Если же атрибуты не вмещаются в отведенное им пространство, создается дополнительная файловая запись (extra FILE Record), ссылающаяся на свою предшественницу.

Листинг 1. Структура файловой записи

FILE Record

    Header              ; заголовок

    Attribute 1         ; атрибут 1

    Attribute 2         ; атрибут 2

    ...                 ; …

    Attribute N         ; атрибут N

End Marker (FFFFFFFFh)  ; маркер конца

Первые четыре байта заголовка оккупированы магической последовательностью «FILE», сигнализирующей о том, что мы имеем дело с файловой записью типа FILE Record. При восстановлении сильно фрагментированного $MFT-файла это обстоятельство играет решающую роль, поскольку позволяет отличить сектора, принадлежащие MFT, от всех остальных. Следом за сигнатурой идет 16-разрядный указатель, содержащий смещение последовательности обновления (update sequence, см. раздел «Последовательности обновления»). Под «указателем» здесь и до конца раздела подразумевается смещение от начала сектора, отсчитываемое от нуля и выраженное в байтах. В NT и W2K это поле всегда равно 002Ah, поэтому для поиска файловых записей можно использовать сигнатуру «FILE*x00», что уменьшает вероятность ложных срабатываний. Правда, в XP и более старших системах последовательность обновления хранится по смещению 002Dh, и поэтому сигнатура приобретает следующий вид «FILE-x00».

Размер заголовка (кстати сказать, варьирующийся от одной операционной системы к другой) в явном виде нигде не хранится, вместо этого в заголовке присутствует указатель на первый атрибут, содержащий его смещение в байтах относительно начала FILE Record, расположенный по смещению 14h байт от начала сектора. Смещения последующих атрибутов (если они есть) определяются путем сложения размеров всех предыдущих атрибутов (размер каждого из атрибутов содержится в его заголовке) со смещением первого атрибута. За концом последнего атрибута находится маркер конца – FFFFFFFFh.

В добавок к этому длина файловой записи хранится в двух полях – 32-разрядное поле реального размера (real size), находящееся по смещению 18h байт от начала сектора, содержит совокупный размер заголовка, всех его атрибутов и маркера конца, округленный по 8-байтной границе. 32-разрядное поле выделенного размера (allocated size), находящееся по смещению 1Сh байт от начала сектора, содержит действительный размер файловой записи в байтах, округленный по размеру сектора. Документация Linux-NTFS Project (версия 0.4) утверждает, что allocated size должен быть кратен размеру кластера, однако в действительности это не так. В частности, на моей машине allocated size равен четвертинке кластера.