Возможности NTFS

Напомню, что в первой части статьи были описаны методы универсального индексирования, управления квотами, средства обеспечения безопасности и точки повторной обработки (reparse points). Все эти возможности предоставляет NTFS версии 5.0 (NTFS5), реализованная в Windows 2000. Во второй части статьи речь пойдет о распределенных связях (Distributed Link Tracking, DLT), функциях для работы с разреженными файлами, контроле изменений томов и шифровании. В заключение я расскажу об альтернативных потоках данных, редко применявшихся до появления NTFS5.

Отслеживание распределенных связей

В Windows Explorer применяется тип символьного указателя, называемый ярлыком (shell link или shell shortcut). Ярлыки, которые мы обычно видим на рабочем столе Windows и в меню Start, обеспечивают удобный доступ к программам и файлам без перехода в соответствующий каталог. Другой тип указателя Windows - OLE-ссылка. OLE-ссылки представляют собой указатели на один из файлов приложения, в котором хранятся данные, принадлежащие другой прикладной программе. Например, если встроить электронную таблицу Excel в документ Word, то OLE-ссылка в документе Word указывает на документ Excel.

Те пользователи, которым хоть раз приходилось перемещать источник ссылки (выполняемую программу) в версии Windows, предшествующей Windows 2000, наблюдали работу эвристического механизма поиска, применяемого Windows Explorer для поиска источника. Если поиск заканчивается неудачей, Windows Explorer прекращает попытки и просит пользователя указать местонахождение источника. DLT автоматически обновляет ярлыки Windows 2000 так, что они указывают на перемещенные источники. Единственное условие - как первоначальное, так и после переноса - источник должен находиться на томе NTFS5 в одном и том же домене.

Для автоматической переадресации ссылок необходима версия NTFS5, так как данная файловая система назначает файлам и каталогам идентификатор объекта длиной 16 байт (128 разрядов). 16 байт - длина глобального уникального идентификатора (GUID) в Windows, и это не случайное совпадение. GUID используется в качестве универсального идентификационного механизма Windows, так как и длина и алгоритм создания GUID практически гарантируют, что каждый GUID уникален. Служба DLT, реализованная в Windows 2000 в виде службы Win32, назначает GUID каждому источнику ссылки, на томе NTFS, и заставляет NTFS записать GUID как идентификатор (ID) объекта-источника. Если щелкнуть на ярлыке или открыть документ со встроенной OLE-ссылкой и при этом путь, указанный в ссылке, не позволяет Windows Explorer обнаружить объект-источник, то Explorer посылает службе DLT запрос о новом местоположении источника. DLT использует ID объекта, предоставленный Explorer, для поиска источника на каждом томе домена, начиная с локальных томов. Обнаружив файл (или каталог), DLT запрашивает у NTFS имя файла и передает результат в Windows Explorer, который обновляет ссылку и связывает ее с обнаруженным томом и каталогом. Таким образом, даже если источник был перемещен на том другого компьютера домена, ссылка остается действительной.

Рисунок 1. Операция $ObjId файла метаданных.

Когда служба DLT (или другое приложение) назначает ID объекта файлу или каталогу, NTFS генерирует атрибут типа $OBJECT_ID в записи таблицы Master File Table (MFT), как показано на Рисунке 1. Этот 16-байтный атрибут хранит GUID. Одновременно NTFS добавляет запись в файл метаданных $Extend$ObjId, который устанавливает соответствие GUID с записью о файле в MFT. Windows 2000 хранит элементы файла метаданных в индексе с именем $O, который NTFS сортирует по ID объекта в B+ дереве. Когда DLT обнаруживает перемещенную ссылку и пытается с ее помощью открыть объект по его ID, NTFS ищет номер MFT-записи ссылки в индексе $O файла $ObjId. Открыв файл с помощью номера в MFT-записи о файле, DLT запрашивает у NTFS имя файла, обновляет ссылку и открывает ее источник. Использование файла $ObjId - пример универсальной индексации, новой функции NTFS, описанной в первой части данной статьи.

Разреженные файлы

Многие приложения состоят из сервера, заносящего данные в файл, и клиента, считывающего данные, записанные сервером. Для реализации подобной архитектуры обычно используется метод, именуемый циклической записью (circular logging), в котором файл имеет фиксированный размер, и, дойдя до конца файла, сервер возвращается к его началу (roll over). При возврате к началу сервер может перезаписать данные, еще не прочитанные клиентом. Другие приложения, такие, как базы данных, формируют чрезвычайно большие файлы, лишь очень малые участки которых заняты значимыми данными. Таким образом, пространство для файла на диске выделено, но не используется. В NTFS5 есть функция для работы с такими разреженными файлами (sparse-file), благодаря которой Windows 2000 в обоих случаях сводит к минимуму нерациональное использование дискового пространства.

Приложение может обозначить неиспользован-ные участки разреженного файла как пустые, освободив дисковое пространство, выделенное для незанятых областей. Сервер будет заносить информацию в файл, не возвращаясь к его началу, а клиент - помечать пустые области файла в процессе чтения. Таким образом, файл может выглядеть очень большим, но занимать мало места на диске. При просмотре свойств файла Windows Explorer показывает оба размера; пространство, реально занимаемое файлом на диске, называется Disk size. Если приложение считывает участок файла, обозначенный как пустой, то получает нулевые данные. В случае с базой данных приложение отмечает неиспользованные фрагменты базы данных как пустые, освобождая дисковое пространство. Структура разреженного файла показана на Рисунке 2.

Рисунок 2. Пространство, занятое разреженным файлом.

Один из методов работы с разреженными файлами всегда использовался в NTFS для сжатия файлов. Алгоритм сжатия NTFS сжимает файлы блоками по 16 кластеров, обычно выделяя для хранения данных менее 16 логических кластеров на диске. Кластер внутри файла называется виртуальным, а кластер на томе - логическим. Между виртуальными и логическими кластерами несжатых файлов существует полное соответствие, но в сжатом файле несколько виртуальных кластеров отображаются на меньшее число логических кластеров. Если приложение читает данные из сжатого файла, то NTFS восстанавливает логические кластеры, составляющие считываемый блок из 16 кластеров, формируя в памяти 16 несжатых логических кластеров. Если блок из 16 кластеров заполнен нулями, то NTFS оптимизирует использование дискового пространства, не выделяя блоку логических кластеров. При чтении этого участка, именуемого разреженной областью (sparse region), NTFS передает приложению нулевые данные.

Функции NTFS для работы с разреженными файлами основаны на тех же подпрограммах драйвера, которые используются для разреженных областей сжатых файлов. Но между разреженными и сжатыми файлами есть два различия. Во-первых, разреженные файлы не сжаты. Во-вторых, приложение может оповестить NTFS о том, что в разреженном файле появилась незаполненная область. Таким образом, ранее выделенные этой области логические кластеры освобождаются. Чтобы создать разреженную область в сжатом файле, приложение должно записать в файл нулевые данные.

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

Контроль изменений тома

До появления Windows 2000 приложения располагали ограниченными средствами для мониторинга изменений тома. Win32 API экспортирует функции, которые сообщают приложению об изменениях содержимого каталога или дерева каталогов. Однако прикладная программа должна просматривать каталоги, своевременно выясняя природу этих изменений, чтобы избежать опасности переполнения буфера приложения сообщениями об изменениях, посылаемыми Windows. Проверка каталогов после каждого изменения слишком сильно снижает производительность, но многим приложениям, например программам резервного копирования, выполняющим инкрементальное копирование, пропускать изменений нельзя. Новые функции контроля изменений тома NTFS5 позволяют приложениям легко отслеживать изменения на томе и служат эффективной альтернативой методам, ранее применявшимся в программах репликации файлов, инкрементального копирования и поиска вирусов.

Рисунок 3. Журнал изменений.

Следует отметить, что в основу функций отслеживания изменений положен механизм разреженных файлов. По умолчанию NTFS отключает контроль изменений тома, поэтому приложение должно само активизировать эти функции. Когда приложение активизирует режим отслеживания изменений тома, NTFS создает журнал изменений (change journal), который представляет собой разреженный файл с именем $Extend$UsnJrnl. Журнал изменений показан на Рисунке 3. Каждому изменению тома, будь то создание, изменение размеров или удаление файла, соответствует запись в альтернативном потоке данных $J (более подробно альтернативные потоки данных будут описаны ниже) файла $UsnJrnl. В записи указывается имя измененного файла, тип и время изменения, а также другие полезные сведения. По запросу приложений NTFS извещает их о появлении в журнале новых записей, и программы могут читать записываемые в журнал данные. Один из клиентов журнала изменений - служба репликации файлов File Replication Service (FRS), используемая для репликации общих каталогов Dfs и распространения групповых политик Windows 2000.

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

Шифрование

Файловая система с шифрованием Encrypting File System (EFS) - важная часть NTFS5.

EFS встроена в NTFS, но представляет собой драйвер расширения (winntsystem32driversefs.sys). EFS обеспечивает прозрачное шифрование файлов, позволяя защитить конфиденциальные данные, которые могут попасть в чужие руки. Хотя система безопасности NTFS предотвращает несанкционированный доступ к файлам на подключенной к сети машине Windows 2000, злоумышленник может обойти защиту, загрузив на компьютере другой экземпляр операционной системы или воспользовавшись утилитой NTFSDOS (ее можно загрузить с www.sysinternals.com/ntfs30.htm), запущенной с загрузочного DOS-диска.

Экран 1. Окно дополнительных атрибутов.

Когда пользователь включает шифрование файла из панели Advanced Attributes диалогового окна свойств файла (см. Экран 1), служба EFS, работающая в локальной подсистеме безопасности LSASS (Local Security Authority Subsystem - winntsystem32lsass.exe), обращается к функциям Crypto API, чтобы выделить пользователю пару из закрытого и открытого ключей, которая применяется EFS для шифрования. EFS генерирует случайный ключ шифрования (FEK) для файла и использует FEK и алгоритм Data Encryption Standard X (DESX) для шифрования данных. DESX - симметричный алгоритм, поэтому в процессе восстановления также используется FEK, и EFS должна защитить его от несанкционированного доступа. Чтобы защитить FEK, EFS шифрует его открытым ключом пользователя с помощью асимметричного алгоритма RSA и сохраняет зашифрованный FEK в файле. Когда пользователь открывает и читает зашифрованный файл, EFS расшифровывает FEK с помощью открытого ключа пользователя, а затем расшифровывает данные файла с помощью восстановленного FEK.

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

Рисунок 4. Хранение зашифрованных ключей.

EFS хранит зашифрованные ключи FEK в атрибуте файла $LOGGED_UTILITY_STREAM (новом для NTFS5), как показано на Рисунке 4. Хранящиеся здесь данные состоят из поля описания данных (Data Dec-ryption Field, DDF) и поля восстановления данных (Data Recovery Field, DRF). В поле DDF хранится копия FEK, зашифрованного с помощью открытого ключа EFS пользователя, а DRF содержит копию FEK, который зашифрован открытым ключом, принадлежащим агенту восстановления системы. На автономной системе агентом восстановления по умолчанию считается локальный администратор; в домене роль агента восстановления играет администратор домена. Поскольку EFS вставляет в каждый файл ключ FEK, зашифрованный с помощью открытого ключа EFS агента восстановления, то авторизованный пользователь может расшифровать файл и восстановить данные в случае, если этого не сможет сделать тот пользователь, который его зашифровал.

Когда система загружается, NTFS читает из реестра параметр HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ControlFileSystemNtfsEncryption Service, чтобы узнать имя драйвера EFS, а затем запускает драйвер. Драйвер EFS регистрирует подпрограммы, напрямую вызываемые NTFS (callback), и NTFS может передать операции с шифрованными файлами драйверу EFS. Внутренние механизмы NTFS для работы с шифрованными и сжатыми файлами очень похожи. NTFS восстанавливает данные сжатого файла и кэш файловой системы Windows 2000 и вновь сжимает данные при записи в файл на диске. Подобным образом NTFS расшифровывает в кэше данные шифрованного файла и вновь шифрует их при записи на диск.

Альтернативный поток данных

Альтернативный поток данных (alternate data stream) - способ встраивания одних файлов в другие. Технически, каждый файл NTFS содержит безымянный встроенный файл. Именно этот файл, называемый стандартным потоком данных (default data stream) или безымянным потоком данных (unnamed data stream), видит перед собой пользователь Notepad, открывающий файл; этот файл встречает приложение, открывающее файл с заданным по умолчанию именем. Прикладные программы могут создавать дополнительные встроенные файлы, называемые альтернативными потоками данных, и давать им различные имена. Для доступа к данным в альтернативных потоках приложения используется синтаксис Win32 API - File: Alter-nateStream (где AlternateStream - имя альтернативного потока).

Первоначально разработчики Micro-soft дополнили NTFS альтернативными потоками, чтобы обеспечить совместимость с системными ресурсами (resource fork) файловой системы Macintosh (Mac). Благодаря возможностям файловой системой Hierar-chical File System (HFS), многие файлы Mac хранят пиктограммы и другую информацию в альтернативных потоках данных. В состав Windows NT Server входят службы Services for Macintosh (SFM - служба, с помощью которой NT обменивается файлами с клиентами Mac), поэтому NT должна поддерживать альтернативные потоки, позволяющие клиентам Mac сохранять файлы с системными ресурсами на серверах NT без потери информации. Из-за ограниченной функциональности альтернативных потоков лишь немногие пользователи NT применяли их. В Windows 2000 роль альтернативных потоков возросла.

Экран 2. Закладка Summary свойств файла.

Закладка Summary (см. Экран 2), которую выводит Windows Explorer в Windows 2000, когда пользователь редактирует свойства файла NTFS, позволяет ассоциировать с файлом произвольную текстовую информацию: например, название, ключевые слова и номер версии. Windows Explorer хранит эту информацию как альтернативный поток данных с именем ?SummaryInformation (знак вопроса замещает непечатаемый символ).

Так как альтернативные потоки данных являются исключением, большинство приложений и команд консоли с ними не работает. Например, Windows Explorer и команда Dir показывают размер только безымянного потока данных.

Провести ряд экспериментов с потоками можно с помощью команд Echo и More, которые поддерживают альтернативные потоки. Сначала необходимо создать файл с альтернативным потоком:

echo hello > file.txt:alternatestream

Чтобы убедиться, что Windows указывает размер файла равным нулю, следует вывести на экран запись файла из перечня каталога, а затем показать данные в альтернативном потоке с помощью команды More:

more < file.txt:alternatestream

Увидеть таким образом потоки суммарной информации Windows Ex-plorer нельзя, так как имя потока суммарной информации начинается с символа, не входящего в набор ASCII.

Узнать, содержатся ли альтернативные потоки данных в файлах и каталогах, можно с помощью бесплатной утилиты Streams (www.sysinternals.com/misc.htm). Данная утилита принимает имя файла или каталога в качестве параметра командной строки и сообщает имена всех альтернативных потоков данных, содержащихся в файле или каталоге. Утилита Streams воспринимает универсальный символ *, а для исследования подкаталогов нужно указать ключ /s, поэтому не составляет труда отыскать все файлы и каталоги с альтернативными потоками на томе или внутри каталога.

Файлы метаданных NTFS

Помимо новых функций в NTFS появились дополнительные метафайлы, в которых хранятся данные, связанные с новой функциональностью. Описывая новые возможности NTFS5, я рассказал о файле метаданных каждой функции. Сводка файлов метаданных NTFS5 приведена в Таблице 1.

Утилита NtfsInfo показывает размер различных файлов метаданных NTFS. В NtfsInfo используется недокументированная функция NTFS, с помощью которой, явно указав имя файла метаданных, можно получить запись каталога для данного файла. Однако NTFS5 не обеспечивает доступ к файлам метаданных, поэтому NtfsInfo в Windows 2000 не работает. Вместо нее для сбора информации обо всех файлах на томе, в том числе и файлах метаданных, можно воспользоваться утилитой NFI (NTFS File Sector Information Utility), представленной в первой части данной статьи.

Перспективы

Значительные усовершенствования NTFS5, в том числе поддержка больших разреженных файлов, функций шифрования и отслеживания изменений, помогут расширить сферу применения Windows 2000. Однако эволюция NTFS продолжается.

Марк Русинович — доктор философии, редактор Windows 2000 Magazine. С ним можно связаться по адресу: mark@sysinternals.com или http://www.sysinternals.com/.