Устройство файловой системы NTFS

Устройство NTFS

Устройство файловой системы NTFS поражает своей грандиозностью и напоминает огромный, окутанный мраком лабиринт. Но какого любителя приключений остановит паутина, скелеты и пара ловушек с ядовитыми стрелами? Хватай факел, и отправимся в путь. Нашим первым квестом будет изучение главной файловой таблицы — MFT и нескольких дочерних структур.

Стандарт файловой системы NTFS версии 3.1 появился в 2001 году с выходом на рынок Windows XP и с тех пор не претерпел фундаментальных изменений. В Windows 10 также используется NTFS v3.1. Архитектуру и особенности внутреннего устройства этой файловой системы Крис Касперски подробно описал в своей книге «Восстановление данных», которая сейчас готовится к переизданию. Мы публикуем отрывок из этой книги, где Крис рассказывает о том, что представляет собой NTFS изнутри.

NTFS с высоты птичьего полета

Основным структурным элементом всякой файловой системы является том (volume), в случае с FAT совпадающий с разделом (partition). NTFS поддерживает тома, состоящие из нескольких разделов (см. рис.). Будем для простоты считать, что том представляет собой отформатированный раздел (то есть раздел, содержащий служебные структуры файловой системы).

Устройство NTFS. Обычный (а) и распределенный (б) тома
Устройство NTFS. Обычный (а) и распределенный (б) тома

Большинство файловых систем трактуют том как совокупность файлов, свободного дискового пространства и служебных структур файловой системы, но в NTFS все служебные структуры представлены файлами, которые (как это и положено файлам) могут находиться в любом месте тома, при необходимости фрагментируя себя на несколько частей.

Основным служебным файлом является главная файловая таблица, $MFT (Master File Table) — своеобразная база данных, хранящая информацию обо всех файлах тома — их именах, атрибутах, способе и порядке размещения на диске. Каталог также является файлом особого типа, со списком принадлежащих ему файлов и вложенных подкаталогов. Важно подчеркнуть, что в MFT присутствуют все файлы, находящиеся во всех подкаталогах тома, поэтому для восстановления диска наличия файла $MFT будет вполне достаточно.

Остальные служебные файлы, называемые метафайлами (metafiles) или метаданными (metadata), всегда имеют имена, начинающиеся со знака доллара ($), и носят сугубо вспомогательный характер, интересный только самой файловой системе. К ним в первую очередь относится: $LogFile — файл транзакций, $Bitmap — карта свободного/занятого пространства, $BadClust — перечень плохих кластеров и т. д. Текущие версии Windows блокируют доступ к служебным файлам с прикладного уровня (даже с правами администратора!), и всякая попытка открытия или создания такого файла в корневом каталоге обречена на неудачу.

Классическое определение, данное в учебниках информатики, отождествляет файл с именованной записью на диске. Большинство файловых систем добавляет к этому понятие атрибута (attribute) — некоторой вспомогательной характеристики, описывающей время создания, права доступа и т. д. В NTFS имя файла, данные файла и его атрибуты полностью уравнены в правах. Иначе говоря, всякий файл NTFS представляет собой совокупность атрибутов, каждый из которых хранится как отдельный поток байтов. Поэтому, во избежание путаницы, атрибуты, хранящие данные файла, часто называют потоками (streams).

РЕКОМЕНДУЕМ:
Как отключить время последнего доступа к файлу в NTFS Windows 10

Каждый атрибут состоит из тела (body) и заголовка (header). Атрибуты подразделяются на резидентные (resident) и нерезидентные (non-resident). Резидентные атрибуты хранятся непосредственно в $MFT, что существенно уменьшает грануляцию дискового пространства и сокращает время доступа. Нерезидентные атрибуты хранят в $MFT лишь свой заголовок, описывающий порядок размещения атрибута на диске.

Назначение атрибута определяется его типом (type), представляющим собой четырехбайтное шестнадцатеричное значение. При желании атрибуту можно дать еще и имя (name), состоящее из символов, входящих в соответствующее пространство имен (namespace). Подавляющее большинство файлов имеет по меньшей мере три атрибута. К их числу относится стандартная информация о файле (время создания, модификации, последнего доступа, права доступа), которая хранится в атрибуте типа 10h, условно обозначаемом $STANDARD_INFORMATION. Ранние версии Windows NT позволяли обращаться к атрибутам по их условным обозначениям, но начиная с Windows 2000 мы лишены этой возможности. Полное имя файла (не путать с путем!) хранится в атрибуте типа 30h ($FILE_NAME).

Если у файла есть одно или несколько альтернативных имен, таких атрибутов может быть и несколько. Здесь же хранится ссылка (file reference) на родительский каталог, позволяющая разобраться, к какому каталогу принадлежит данный файл или подкаталог. По умолчанию данные файла хранятся в безымянном атрибуте типа 80h ($DATA). Однако при желании прикладные программы могут создавать дополнительные потоки данных, отделяя имя атрибута от имени файла знаком двоеточия (например: ECHO xxx > file:attr1; ECHO yyy > file:attr2; more < file:attr1; more < file:attr2).

Изначально в NTFS была заложена способность индексации любых атрибутов, значительно сокращающая время поиска файла по заданному списку критериев (например, времени последнего доступа). Индексы хранятся в виде двоичных деревьев, поэтому среднее время выполнения запроса оценивается как O(lg n). На практике в большинстве драйверов NTFS реализована индексация лишь по имени файла. Как уже говорилось ранее, каталог представляет собой файл особого типа — файл индексов. В отличие от FAT, где файл каталога представляет собой единственный источник данных об организации файлов, в NTFS файл каталога используется лишь для ускорения доступа к содержимому каталога. Он не является обязательным, так как ссылка на родительский каталог всякого файла в обязательном порядке присутствует в атрибуте его имени ($FILE_NAME).

Каждый атрибут может быть зашифрован, разрежен или сжат. Техника работы с такими атрибутами выходит далеко за рамки первичного знакомства с организацией файловой системы. Мы же рассмотрим углубленно фундамент файловой системы NTFS — структуру $MFT.

Главная файловая таблица

В процессе форматирования логического раздела в его начале создается так называемая зона MFT (см. рис.). По умолчанию она занимает 12,5% от емкости тома (а не 12%, как утверждается во многих публикациях), хотя, в зависимости от значения параметра NtfsMftZoneReservation, она может составлять 25, 37 или 50%.

Устройство NTFS. Структура тома, отформатированного под NTFS
Устройство NTFS. Структура тома, отформатированного под NTFS

В этой области расположен файл $MFT, изначально занимающий порядка 64 секторов и растущий от начала зоны MFT к ее концу по мере создания новых пользовательских файлов и каталогов. Чем больше файлов содержится на томе, тем больше размер MFT. Приблизительный размер файла $MFT можно оценить по следующей формуле: sizeof(FILE Record) N Files, где sizeof(FILE Record) обычно составляет 1 Кбайт, а N Files — полное количество файлов и подкаталогов раздела, включая недавно удаленные.

Для предотвращения фрагментации файла $MFT зона MFT удерживается зарезервированной вплоть до полного исчерпания свободного пространства тома, затем незадействованный «хвост» зоны MFT усекается в два раза, освобождая место для пользовательских файлов. Этот процесс может повторяться многократно, вплоть до полной отдачи всего зарезервированного пространства. Решение красивое, хотя и не новое. Многие из файловых систем восьмидесятых годов прошлого века позволяли резервировать заданное дисковое пространство в хвосте активных файлов, сокращая их фрагментацию (причем любых файлов, а не только служебных). Например, такая способность была у DOS 3.0, разработанной для персональных компьютеров типа «Агат». Может быть, кто-то из вас помнит такую машину?

Когда файл $MFT достигает границ зоны MFT, в ходе своего последующего роста он неизбежно фрагментируется, вызывая обвальное падение производительности файловой системы. При этом стоит заметить, что подавляющее большинство дефрагментаторов файл $MFT не обрабатывают! А ведь API дефрагментации, встроенный в штатный драйвер NTFS, обеспечивает такую возможность!

При необходимости файл $MFT может быть перемещен в любую часть диска, и тогда в начале тома его уже не окажется. Стартовый адрес файла $MFT хранится в загрузочном секторе по смещению 30h байт от его начала. B подавляющем большинстве случаев этот адрес ссылается на четвертый кластер.

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

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

Смещение Размер (байт) Описание
00h 6 Индекс файловой записи (FILE record number), отсчитываемый от нуля
06h 2 Номер последовательности (sequence number)

При удалении файла или каталога соответствующая ему файловая последовательность помечается как неиспользуемая. При создании новых файлов записи, помеченные как неиспользуемые, могут задействоваться вновь, при этом счетчик номера последовательности, хранящийся внутри файловой записи, увеличивается на единицу. Этот механизм позволяет отслеживать «мертвые» ссылки на уже удаленные файлы. Номер последовательности внутри файловой ссылки в этом случае будет отличаться от номера последовательности соответствующей файловой записи.

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

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

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

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

Файловые записи

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

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

Первые четыре байта заголовка заняты «магической последовательностью» FILE, сигнализирующей о том, что мы имеем дело с файловой записью типа FILE Record. При восстановлении сильно фрагментированного файла $MFT это обстоятельство играет решающую роль, поскольку позволяет отличить сектора, принадлежащие MFT, от всех остальных секторов.

Следом за сигнатурой идет 16-разрядный указатель, содержащий смещение последовательности обновления (update sequence). Под «указателем» здесь и до конца раздела подразумевается смещение от начала сектора, отсчитываемое от нуля и выраженное в байтах. Последовательность обновления хранится по смещению 002Dh, и поэтому сигнатура приобретает следующий вид: FILE-\x00.

Размер заголовка варьируется от одной версии операционной системы к другой и в явном виде нигде не хранится. Вместо этого в заголовке присутствует указатель на первый атрибут, содержащий его смещение в байтах относительно начала файловой записи и расположенный по смещению 14h байт от начала сектора.

Смещения последующих атрибутов (если они есть) определяются путем сложения размеров всех предыдущих атрибутов (размер каждого из атрибутов содержится в его заголовке) со смещением первого атрибута. За концом последнего атрибута находится маркер конца — значение FFFFFFFFh.

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

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

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

Последовательность обновления

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

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

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

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

По смещению 006h от начала сектора находится 16-разрядное поле, хранящее совокупный размер номера последовательности обновления вместе с массивом последовательности обновления (sizeof(update sequence number) + sizeof(update sequence array)), выраженный в словах (не в байтах!). Так как размер номера последовательности обновления всегда равен одному слову, то размер массива последовательности обновления, выраженный в байтах, должен вычисляться следующим образом: (update sequence number & update sequence array 1)*2. Таким образом, смещение массива оригинального содержимого равно (offset to update sequence number) + 2.
В Windows XP и более новых операционных системах эти значения располагаются по смещениям 2Dh и 2Fh соответственно. Первое слово массива последовательности обновления соответствует последнему слову первого сектора файловой записи или индексной записи. Второе — последнему слову второго сектора и т. д.

Атрибуты

Структурно всякий атрибут состоит из атрибутного заголовка (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 байт от начала атрибутного заголовка, не равно нулю.

Типы атрибутов

NTFS поддерживает большее количество предопределенных типов атрибутов. Тип атрибута определяет его назначение и формат представления тела. Полное описание всех атрибутов заняло бы целую книгу, поэтому кратко перечислю лишь наиболее «ходовые» из них. Так, атрибут стандартной информации $STANDARD_INFORMATION описывает время создания, изменения и последнего доступа к файлу, права доступа, а также некоторую другую вспомогательную информацию (например, квоты).

Атрибут списка атрибутов (прямо каламбур) $ATTRIBUTE_LIST используется в тех случаях, когда все атрибуты файла не умещаются в базовой файловой записи и файловая система вынуждена располагать их в расширенных файловых записях. Индексы расширенных файловых записей содержатся в атрибуте списка атрибутов, помещаемом в базовую файловую запись.

При каких обстоятельствах атрибуты не умещаются в одной файловой записи? Это может произойти в следующих случаях:

  • файл содержит много альтернативных имен или жестких ссылок;
  • файл сильно фрагментирован;
  • файл содержит очень сложный дескриптор безопасности;
  • файл имеет очень много потоков данных (т. е. атрибутов типа $DATA).

Атрибут полного имени файла $FILE_NAME хранит имя файла в соответствующем пространстве имен. Таких атрибутов у файла может быть и несколько. Здесь же хранятся и жесткие ссылки (hard link), если они есть.

Списки отрезков

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

Внутренний формат представления списков не то чтобы сложен, но простым его тоже не назовешь. Для экономии места длина отрезка и номер начального кластера хранятся в полях переменной длины. Если размер отрезка умещается в байт (т. е. его значение не превышает 255), то он займет один байт. По аналогии, если размер отрезка требует для своего представления двойного слова, то он займет двойное слово.

Сами же поля размеров хранятся в 4-битных ячейках, называемых нибблами (nibble) или полубайтами. Шестнадцатеричная система счисления позволяет легко переводить байты в нибблы и наоборот. Младший ниббл равен (X & 15), а старший — (X / 16). Иначе говоря, младший ниббл соответствует младшему шестнадцатеричному разряду байта, а старший — старшему. Например, 69h состоит из двух нибблов, причем младший равен 9h, а старший — 6h.

Список отрезков представляет собой массив структур, каждая из которых описывает характеристики «своего» отрезка. В конце списка находится завершающий ноль. Первый байт структуры состоит из двух нибблов: младший задает длину поля начального кластера отрезка (условно обозначаемого буквой F), а старший — количество кластеров в отрезке (L). Затем идет поле длины отрезка. В зависимости от значения L оно может занимать от одного до восьми байт (поля большей длины недопустимы). Первый байт поля стартового кластера файла расположен по смещению 1 + L байт от начала структуры (что соответствует 2+2*L нибблам). Вот как выглядит структура одного элемента списка отрезков.

Смещение в нибблах Размер в нибблах Описание
0 1 Размер поля длины (L)
1 1 Размер поля начального кластера (S)
2 2*L Количество кластеров в отрезке
2+2*L 2*S Номер начального кластера отрезка

Начиная с версии 3.0 NTFS поддерживает разреженные (sparse) атрибуты, т. е. такие атрибуты, которые не записывают на диск кластеры, содержащие одни нули. При этом поле номера начального кластера отрезка может быть равным нулю, что означает, что данному отрезку не выделен никакой кластер. Поле длины содержит количество кластеров, заполненных нулями.

Назначение служебных файлов

NTFS содержит большое количество служебных файлов (метафайлов) строго определенного формата. Важнейший из метафайлов, $MFT, мы только что рассмотрели. Остальные метафайлы играют вспомогательную роль. Тем не менее если они окажутся искажены, то штатный драйвер файловой системы не сможет работать с таким томом, поэтому иметь некоторые представления о назначении каждого из них все же необходимо.

Краткие сведения о назначении важнейших метафайлов приведены в следующей таблице. К сожалению, в пределах одной статьи нет возможности подробно рассмотреть структуру всех существующих метафайлов, но, по крайней мере, можно составить общее представление об их назначении.

Назначение основных метафайлов NTFS

Inode Имя файла ОС Описание
0 $MFT Любая Главная файловая таблица (Master File Table, MFT)
1 $MFTMirr Любая Резервная копия первых четырех элементов MFT
2 $LogFile Любая Журнал транзакций (transactional logging file)
3 $Volume Любая Серийный номер, время создания, флаг
несброшенного кеша (dirty flag) тома
4 $AttrDef Любая Определение атрибутов
5 . (точка) Любая Корневой каталог (root directory) тома
6 $Bitmap Любая Карта свободного/занятого пространства
7 $Boot Любая Загрузочная запись (boot record) тома
8 $BadClus Любая Список плохих кластеров (bad clusters) тома
9 $Quota Windows NT Информация о квотах (quota information)
9 $Secure Windows 2000 и позже Использованные дескрипторы безопасности (security descriptors)
10 $UpCase Любая Таблица заглавных символов (uppercase characters ) для трансляции имен
11 $Extend Windows 2000 и позже Каталоги: $ObjId, $Quota, $Reparse, $UsnJrnl
12–15 не используется Любая Помечены как использованные, но в действительности пустые
16–23 не используется Любая Помечены как неиспользуемые
Любой $ObjId Windows 2000 и позже Уникальные идентификаторы каждого файла
Любой $Quota Windows 2000 и позже Информация о квотах (quota information)
Любой $Reparse Windows 2000 и позже Информация о точке передачи (reparse point)
Любой $UsnJrnl Windows 2000 и позже Журнал шифрованной файловой системы (journaling of encryption)
> 24 Пользовательский файл Любая Обычные файлы
> 24 Пользовательский каталог Любая Обычные каталоги

Заключение

Мы рассмотрели общую структуру NTFS версии 3.1, которая используется начиная с Windows XP и заканчивая Windows Server 2019, включая, конечно же, Windows 10. Эта информация поможет тебе лучше понять, как Windows хранит файлы, а также может пригодиться в процессе восстановления поврежденных данных. Конечно же, подробное описание архитектуры NTFS может занять отдельную и весьма объемную книгу (которых, кстати, существует немало), но за подробностями ты всегда можешь обратиться к технической документации.

Звёзд: 1Звёзд: 2Звёзд: 3Звёзд: 4Звёзд: 5 (2 оценок, среднее: 4,00 из 5)
Загрузка...
Понравилась статья? Поделиться с друзьями:
Добавить комментарий