Обзор NTFS с высоты птичьего полета

При необходимости, $MFT-файл может быть перемещен в любую часть диска и тогда в начале тома его уже не окажется. Стартовый адрес $MFT-файла хранится в Boot-секторе по смещению 30h байт от его начала (см. " boot-сектор", описанный в предыдущей статье данного цикла) и в подавляющем большинстве случаев этот адрес ссылается на 4-й кластер.

Рисунок 2. Cтруктура дискового тома под NTFS.

$MFT-файл представляет собой массив записей типа FILE Record (или в терминологии UNIX - inodes), каждая из которых описывает соответствующий ей файл или подкаталог (подробнее см. " Файловые записи"). В подавляющем большинстве случаев один файл/подкаталог полностью описывается одной-единственной записью FILE Record, хотя, теоретически, этих записей может потребоваться и несколько.

Для ссылки на одну файловую запись из другой используется ее порядковый номер (он же индекс) в $MFT файле, отсчитываемый от нуля. Файловая ссылка (file reference) состоит из двух частей (см. таблицу 2) - 48-битного индекса и 16-битного номера последовательности (sequence number).

При удалении файла/каталога соответствующая ему файловая последовательность помечается как неиспользуемая. При создании новых файлов записи, помеченные как неиспользуемые, могут задействоваться вновь, при этом счетчик номера последовательности, хранящийся внутри файловой записи, увеличивается на единицу. Этот механизм позволяет отслеживать " мертвые" ссылки на уже удаленные файлы - очевидно, sequence number внутри file reference будет отличается от номера последовательности соответствующей файловой записи (этой проверкой занимается утилита chkdsk и автоматически, насколько мне известно, она не выполняется).

Таблица 2. Структура файловой ссылки (file reference).

Первые 12 записей в MFT всегда занимают служебные метафайлы: $MFT (собственно, сам $MFT), $MFTMirr (зеркало $MFT), $LogFile (файл транзакций), $Volume (сведения о дисковом томе), $AttrDef (определенные атрибуты), '.' (корневой каталог), $Bitmap (карта свободного пространства), $Boot (системный загрузчик), $BadClus (перечень плохих кластеров) и т.д. Подробнее см. таблицу 11.

Первые четыре записи настолько важны, что продублированы в специальном $MFTMirr-файле, находящимся приблизительно посередине диска (точное расположение хранится в boot-секторе по смещению 38h байт от его начала). Вопреки своему названию, $MFTMirr это отнюдь не зеркало всего $MFT-файла, это всего лишь копия первых четырех элементов.

Записи с 12 по 15 помечены как используемые, но в действительности же они пусты (как нетрудно догадаться, это задел на будущее). Записи с 16 по 23 не задействованы и честно помечены как неиспользуемые.

Начиная с 24-й записи, располагаются пользовательские файлы и каталоги. Четыре метафайла, появившихся в W2K - $ObjId, $Quota, $Reparse и $UsnJrnl могут располагаться в любой записи, номер которой равен 24 или больше (как мы помним, номера файловых записей отсчитываются, начиная с нуля).

Для знакомства с MFT запустим DiskExplorer от Runtime Software, не забывая о том, что он требует прав администратора, в меню " File" найдем пункт " Drive" и в открывшемся диалоговом окне выберем логический диск, который мы хотим редактировать. Затем в меню " Goto" выберем пункт " Mft", заставляя DiskExplorer перейти к MFT, автоматически меняя режим отображения на наиболее естественный (см. рис. 3). Как вариант, можно нажать < F6> (View as File Entry) и промотать несколько первых секторов клавишей < Page Down>.

Для каждого из файлов DiskExplorer сообщает:

1) Номер сектора, к которому данная файловая запись принадлежит (обратите внимание, что номера секторов монотонно увеличиваются на 2, подтверждая тот факт, что размер одной файловой записи равен 1 Кбайту, однако вы можете столкнуться и с другими значениями). Для удобства информация отображается сразу в двух системах исчисления - шестнадцатеричной и десятичной;

2) Основное имя файла/каталога (т.е. имя файла из заголовка файловой записи; некоторые файлы имеют несколько альтернативных имен, подробнее см. " Атрибуты"). Если имя файла/каталога зачеркнуто, значит он был удален, но соответствующая ему файловая запись все еще цела. Чтобы извлечь файл с диска (неважно, удаленный или нет) подведите к нему курсор и нажните < Ctrl-T> для просмотра его содержимого в шестнадцатеричном виде или < Ctrl-S> для сохранения файла на диск. То же самое можно сделать и через контекстное меню (раздел " recovery"). При нажатии на < Ctrl-C> в буфер обмена копируется последовательность кластеров, занятых файлом (например, " DISKEXPL: K: 1034240-1034240").

3) Тип файловой записи - файл это или каталог?

4) Атрибуты файла/каталога - a = архивный файл, r = только на чтение, h = скрытый, s = системный, l = метка тома, d = каталог, c = сжатый файл;

5) Размер файла в байтах в десятичной системе исчисления (не для каталогов!);

6) Дату и время модификации файла/каталога;

7) Номер первого кластера файла/каталога (или " resident" для полностью резидентных файлов/каталогов);

8) Перечень типов NTFS-атрибутов, имеющихся у файла/каталога, записанных в шестнадцатеричной нотации (обычно эта строка имеет вид 10 30 80 - атрибут стандартной информации, атрибут имени и атрибут данных файла, подробнее см. " Типы атрибутов");

9) Индекс файловой записи в MFT, выраженный в шестнадцатеричной и десятичной системах исчисления и следующий за словом " No: " (сокращение от Number - номер);

10) Индекс файловой записи материнского каталога, выраженный в шестнадцатеричной и десятичной системах исчисления (5h - если файл принадлежит к корневому каталогу). Для быстрого перемещения по файловым записям выберите в меню " Goto" пункт " Mft no" и введите требуемый индекс в шестнадцатеричной или десятичной форме;

11) Для нерезидентных файлов/каталогов - перечень кластеров, занятых файлов в недекодированном виде (а зря - могли бы и декодировать!). Схема кодирования кластеров подробно описана в главе " Списки отрезков".

Прежде чем продолжать чтение статьи, попробуйте поэкспериментировать в MFT файлами (особенно фрагментированными). Посмотрите, как создаются и удаляются записи из MFT. Лучше всего это делать на диске, содержащим небольшое количество файлов/каталогов. Чтобы не форматировать логический диск, создайте виртуальный (благо количество оперативной памяти современных компьютеров это позволяет).

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

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

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

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

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

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

Первые четыре байта заголовка оккупированы магической последовательностью " 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 равен четвертинке кластера.

16-разрядное поле флагов, находящееся по смещению 16h байт от начала сектора, в подавляющем большинстве случаев принимает одно из трех следующих значений: 00h - данная файловая запись не используется или ассоциированный с ней файл/каталог удален, 01h - файловая запись используется и описывает файл, 02h - файловая запись используется и описывает каталог.

64-разрядное поле, находящееся по смещению 20h байт от начала сектора содержит индекс базовой файловой записи. Для первой файловой записи это поле всегда равно нулю, а для всех последующих, расширенных (extra) записей - индексу первой файловой записи. Расширенные файловые записи могут находиться в любых частях MFT, не обязательно рядом с основной записью. А коль скоро так, необходим какой-то механизм, обеспечивающий быстрый поиск расширенных файловых записей, принадлежащих данному файлу (просматривать весь MFT целиком не предлагать!). И этот механизм основан на ведении списков атрибутов $ATTRIBUTE_LIST. Список атрибутов представляет собой специальный атрибут, добавляемый к первой файловой записи и содержащий индексы расширенных записей. Формат списка атрибутов приведен в разделе " типы атрибутов".

Остальные поля заголовка файловой записи не столь важны и поэтому здесь не рассматриваются. При необходимости обращайтесь к документации " Linux-NTFS Project".

Таблица 3. Структура заголовка файловой записи (FILE Record).

Последовательности обновления (update sequence)

Будучи очень важными компонентами файловой системы, $MFT, INDEX и $LogFile нуждаются в механизме контроля целостности своего содержимого. Традиционно для этого используется ECC/EDC-коды, однако во времена проектирования NTFS процессоры были не настолько быстрыми, как теперь и расчет корректирующих кодов занимал значительное время, существенно снижающее производительность файловой системы. Поэтому от них пришлось отказаться. Вместо этого, разработчики NTFS применили так называемые последовательности обновления (update sequence), также называемые fix-up 'ами.

В конец каждого из секторов, слагающих файловую запись (INDEX Record, RCRD Record или RSTR Record) записывается специальный 16-байтовый номер последовательности обновления (update sequence number), дублируемый в заголовке файловой записи. При каждой операции чтения два последних байта сектора сверяется с соответствующим полем заголовка и если NTFS-драйвер обнаруживает расхождение, данная файловая запись считается недействительной.

Основное назначение последовательностей обновления - защита от " обрыва записи". Если в процессе записи сектора на диск, исчезнет питающее напряжение, может случиться так, что половина файловой записи будет успешно записана, а половина - сохранит прежнее содержимое (файловая запись, как мы помним, обычно состоит из двух секторов). После восстановления питания, драйвер файловой системы не может уверенно сказать - была ли файловая запись записана целиком или нет. Вот тут-то последовательности обновления и выручают! При каждой перезаписи сектора update sequence увеличивается на единицу и потому, если произошел обрыв записи, значение последовательности обновления, находящейся в заголовке файловой записи не будет совпадать с последовательностью обновления, расположенной в конце сектора.

Оригинальное содержимое, расположенное " под" последовательностью обновления, хранится в специальном массиве обновления (update sequence array), расположенном в заголовке файловой записи непосредственно за концом update sequence number. Для восстановления файловой записи в исходный вид мы должны извлечь из заголовка указатель на update sequence number (он хранится по смещению 04h байт от начала заголовка) и сверить лежащее по этому адресу 16-байтное значение с последним словом каждого из секторов, слагающих файловую запись (INDEX Record, RCRD Record или RSTR Record). Если они не совпадут, значит соответствующая структура данных повреждена и использовать ее следует с очень большой осторожностью (а на первых порах лучше не использовать вообще).

По смещению 006h от начала сектора находится 16-разрядное поле, хранящее совокупный размер номера последовательности обновления вместе с массивном последовательности обновления (sizeof(update sequence number) + sizeif(update sequence array)), выраженный в словах (не в байтах!). Поскольку размер номера последовательности обновления всегда равен одному слову, то размер массива последовательности обновления, выпаженный в байтах, равен: (update sequence number & update sequence array ‑ 1) * 2. Соответственно, смещение массива оригинального содержимого равно (offset to update sequence number) + 2. В NT и W2K update sequence number всегда располагается по смещению 2Ah от начала FILE Record Header/INDEX Header, а update sequence array - по смещению 2Сh. В XP же и более старших системах - по смещениям 2Dh и 2Fh соответственно.

Первое слово массива последовательности обновления соответствует последнему слову первого сектора FILE Record/INDEX. Второе - последнему слову второго сектора, и т.д. Для восстановления сектора в исходный вид мы должны вернуть все элементы массива последовательности обновления на их законные места (естественно, модифицируется не сам сектор, а его копия в памяти).

Продемонстрируем это на следующем примере:

Листинг 2. Оригинальная файловая запись до восстановления.

Сигнатура " FILE" указывает на начало файловой записи. А раз так, то по смещению 04h байт будет расположен 16-разрядный указатель на номер последовательности обновления. В данном случае он равен 002Ah. Ок, переходим по смещению 002Ah и видим, что здесь лежит слово 0006h. Перемещаемся в конец сектора и сверяем его с последними двумя байтами. Как и предполагалось, они совпадают. Повторяем ту же самую операцию со следующим сектором. Собственно говоря, количество секторов может и не равняться двум. Чтобы не гадать на кофейной гуще, необходимо извлечь 16-разрядное значение, расположенное по смещению 06h от начала файловой записи (в данном случае оно равно 0003h) и вычесть из него единицу. Действительно, получается два (сектора).

Теперь нам необходимо найти массив последовательности обновления, хранящий оригинальное значение последнего слова каждого из секторов. Смещение массива обновления равно значению указателя на последовательность обновления, увеличенной на два, т.е. в данном случае 002Ah + 02h = 002Ch. Извлекаем первое слово (в данном случае равное 00h 00h) и записываем его в конец первого сектора. Извлекаем следующее слово (47h 11h) и записываем его в конец второго сектора.

В результате чего восстановленный сектор будет выглядеть так:

Листинг 3. Восстановленная файловая запись.

Внимание! FILE Record, INDEX Record, RCRD Record или RSTR Record искажены последовательностями обновления и в обязательном порядке должны быть восстановлены перед их использованием, в противном случае вместо актуальных данных вы получите мусор!

Атрибуты (attribute)

Структурно всякий атрибут стоит из атрибутного заголовка (attribute header) и тела атрибута (attribute body). Заголовок атрибута всегда хранится в файловой записи, расположенной внутри MFT (см. " Файловые записи"). Тела резидентных атрибутов хранятся там же. Нерезидентные атрибуты хранят свое тело вне MFT в одном или нескольких кластерах, перечисленных в заголовке данного атрибута в специальном списке (см. " Списки отрезков"). Если 8-разрдное поле, расположенное по смещению 08h байт от начала атрибутного заголовка, равно нулю - атрибут считается резидентным, а если единице, то - нет. Любые другие значения недопустимы.

Первые четыре байта атрибутного заголовка определяют его тип. Тип атрибута в свою очередь определяет формат представления тела атрибута. В частности, тело атрибута данных (тип: 80h - $DATA) представляет собой " сырую" последовательность байт. Тело атрибута стандартной информации (тип: 10h - $STANDARD_INFORMATION) описывает время его создания, права доступа и т.д. Подробнее см. " Типы атрибутов".

Следующие четыре байта заголовка содержат длину атрибута, выражаемую в байтах. Длина нерезидентного атрибута равна сумме длин его тела и заголовка, а длина резидентного атрибута равна длине его заголовка. Короче говоря, если к смещению атрибута добавить его длину, мы получим указатель на следующий атрибут (или маркер конца, если текущий атрибут - последний в цепочке).

Длина тела резидентных атрибутов, выраженная в байтах, хранится в 32-разрядном поле, расположенном по смещению 10h байт от начала атрибутного заголовка. 16-разрядное поле, следующее за его концом, хранит смещение резидентного тела, отсчитываемое от начала атрибутного заголовка. С нерезидентными атрибутами в этом плане все намного сложнее и для хранения длины их тела используется множество полей. Реальный размер тела атрибута (real size of attribute), выраженный в байтах, хранится в 64-разрядном поле, находящимся по смещению 30h байт от начала атрибутного заголовка. Следующее за ним 64-разрядное поле хранит инициализированный размер потока (initialized data size of the stream), выраженный в байтах и, судя по всему, всегда равный реальному размеру тела атрибута. 64-разрядное поле, расположенное по смещению 28h байт от начала атрибутного заголовка, хранит выделенный размер (allocated size of attribute), выраженный в байтах и равный реальному размеру тела атрибута округленному до размера кластера (в большую сторону).

Два 64-разрядных поля, расположенные по смещению 10h и 18h байт от начала атрибутного заголовка задают первый (starting VCN) и последний (last VCN) номер виртуального кластера, принадлежащего телу нерезидентного атрибута. Виртуальные кластеры представляют собой логические номера кластеров, не зависящие от своего физического расположения на диске. В подавляющем большинстве случаев номер первого кластера тела нерезидентного атрибута равен нулю, а последний - количеству кластеров занятых телом атрибута, уменьшенном на единицу. 16-разрядное поле, расположенное по смещению 20h от начала атрибутного заголовка содержит указатель на массив Data Runs, расположенный внутри этого заголовка и описывающий логический порядок размещения нерезидентного тела атрибута на диске (подробнее см. " Списки отрезков").

Каждый атрибут имеет свой собственный идентификатор (attribute ID), уникальный для данной файловой записи и хранящийся в 16-разрядном поле, расположенном по смещению 0Eh от начала атрибутного заголовка.

Если атрибут имеет имя (attribute Name), то 16-разрядное поле, расположенное по смещению 0Ah байт от атрибутного заголовка, содержит указатель на него. Для безымянных атрибутов оно равно нулю (а большинство атрибутов безымянны!). Имя атрибута хранится в атрибутном заголовке в формате UNICODE, а его длина определяется 8-разрядным полем, расположенным по смещению 09h байт от начала атрибутного заголовка.

Если тело атрибута сжато, зашифровано или разряжено, 16-разряное поле флагов, расположенное по смещению 0Ch байт от начала атрибутного заголовка не равно нулю.

Остальные поля не играют сколь-нибудь существенной роли и потому здесь не рассматриваются.

Таблица 4. Структура резидентного атрибута.

Таблица 5. Структура нерезидентного атрибута.