NTFS изначально проектировалась как файловая система, не зависящая от платформы, способная работать с большим количеством различных подсистем, в том числе: Win32, MS-DOS, POSIX. Так как каждая из перечисленных подсистем налагает собственные ограничения на набор символов, допустимых для использования в имени файла, NTFS вынуждена поддерживать несколько независимых пространств имен (name spaces).
POSIX
Допустимы все символы UNICODE (с учетом регистра), за исключением символа нуля (
NULL
), обратной косой черты (
\
) и знака двоеточия (
:
). Последнее из перечисленных ограничений, кстати говоря, не есть ограничение POSIX. Напротив, это — внутреннее ограничение файловой системы NTFS, использующей этот символ для доступа к именованным атрибутам. Максимально допустимая длина имени составляет 255 символов.
Win32
Доступны все символы UNICODE (без учета регистра), за исключением следующего набора: кавычки (
"
),
звездочка (
*
), косая черта (
/
), двоеточие (
:
), знак "меньше" (
<
), знак "больше" (
>
), вопросительный знак (
?
), обратная косая черта (
\
), а также символ конвейера (
|
). Кроме того, имя файла не может заканчиваться точкой или пробелом. Максимально допустимая длина имени составляет 255 символов.
MS-DOS
Доступны все символы пространства имен Win32 (без учета регистра), за исключением следующих: знак плюса (
+
), запятая (
,
), точка (
.
), точка с запятой (
;
), знак равенства (
=
). Длина имени файла не должна превышать восьми символов, за которыми следует необязательное расширение имени файла, имеющее длину от одного до трех символов.
Назначение служебных файлов
NTFS содержит большое количество служебных файлов (метафайлов) строго определенного формата. Важнейший из метафайлов,
$MFT
, мы только что рассмотрели. Остальные метафайлы играют вспомогательную роль. Для восстановления данных детально знать их структуру необязательно. Тем не менее, если они окажутся искажены, то штатный драйвер файловой системы не сможет работать с таким томом, поэтому иметь некоторые представления о назначении каждого из них все же необходимо.
Краткие сведения о назначении важнейших метафайлов приведены в табл. 6.11. К сожалению, в пределах одной главы нет возможности подробно рассмотреть структуру всех существующих метафайлов, поэтому заинтересованным читателям рекомендуется искать эту информацию в документации к Linux-NTFS Project.
Таблица 6.11. Назначение основных метафайлов 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 был бы неполным без практической иллюстрации техники разбора файловой записи вручную. До сих пор мы витали в облаках теоретической абстракции. Пора спускаться на грешную землю.
Воспользовавшись любым дисковым редактором, например, Disk Probe, попробуем декодировать одну файловую запись вручную. Найдем сектор, содержащий сигнатуру
FILE
в его начале (не обязательно брать первый встретившийся сектор). Он может выглядеть, например, как в листинге 6.4.
Листинг 6.4. Ручное декодирование файловой записи (разные атрибуты выделены разным цветом)
Первым делом необходимо восстановить оригинальное содержимое последовательности обновления. По смещению
04h
от начала сектора лежит 16-разрядный указатель на нее, равный в данном случае
2Ah
(значит, это NTFS 3.0 или более ранняя версия). А что у нас лежит по смещению
2Ah
? Это — пара байт
03 00
. Данная последовательность представляет собой номер последовательности обновления. Сверяем его с содержимым двух последних байт этого и следующего секторов (смещения
1FEh
и
3FEh
соответственно). Они равны! Следовательно, данная файловая запись цела (по крайней мере, на первый взгляд), и можно переходить к операции ее восстановления. По смещению
2Ch
расположен массив, содержащий оригинальные значения последовательности обновления. Количество элементов в нем равно содержимому 16-разрядного поля, расположенному по смещению
06h
от начала сектора и уменьшенного на единицу (в данном случае имеем
03h - 01h == 02h
). Извлекаем два слова, начиная со смещения
2Ch
(в данном случае они равны
00 00
и
00 00
) и записываем их в конец первого и последнего секторов.