DeviceIoControl.
Процесс может запросить содержимое точки повторного разбора с помощью управляющего кода FSCTL_GET_REPARSE_POINT. B атрибутах файла, сопоставленного с точкой повторного разбора, присутствует флаг FILEAT-TRIBUTE_REPARSE_POINT, что позволяет приложениям проверять наличие точек повторного разбора вызовом Windows-функции GetFileAttributes.
ЭКСПЕРИМЕНТ: создание точки соединения
B Windows нет средств для создания точек соединения, но вы можете создать такую точку с помощью утилиты Junction ( wwwsysinternak.com )или Linkd из ресурсов Windows. Утилита Linkd позволяет просмотреть определения существующих точек соединения, a Junction – вывести информацию о точках соединения и точках повторного разбора.
Приложения сжимают и разархивируют файлы, передавая DeviceIoControlуправляющий код FSCTL_SET_COMPRESSION. Для запроса состояния сжатия файла или каталога используется управляющий код FSCTL_GET_COMPRES-SION. У сжатого файла или каталога установлен флаг FILE_ATTRIBUTE_COM-PRESSED, поэтому приложения могут определять состояние сжатия файла или каталога вызовом GetFileAttributes.
Второй тип сжатия известен под названием разреженные файлы(sparse files). Если файл помечен как разреженный, NTFS не выделяет на томе место для тех частей файла, которые определены приложением как пустые. При чтении приложением пустых областей разреженного файла NTFS просто возвращает буферы, заполненные нулевыми значениями. Этот тип сжатия полезен для клиент-серверных приложений, в которых реализовано протоколирование с циклическими буферами (circular-buffer logging): сервер регистрирует информацию в файле, а клиент асинхронно считывает ее. Поскольку информация, уже считанная клиентом, больше не нужна, продолжать хранить ее в файле не требуется. Если такой файл является разреженным, клиент может определять считанные им области как пустые, тем самым освобождая место на томе. A сервер может добавлять новую информацию в файл, не опасаясь, что он в конечном счете займет все свободное пространство на томе.
Как и в случае сжатых файлов, NTFS прозрачно управляет разреженными файлами. Приложения указывают состояние разреженности файла, передавая DeviceIoControlуправляющий код FSCTL_SET_SPARSE. Чтобы определить диапазон файла как пустой, приложения используют код FSCTL_SET_ 2ERO_DATA, а чтобы запросить у NTFS описание того, какие части файла являются разреженными, – код FSCTL_QUERY_ALLOCATED_RANGES. Разреженные файлы применяются, в частности, в журнале изменений NTFS, о котором мы расскажем в следующем разделе.
Альтернативный подход для приложения заключается в том, чтобы зарегистрироваться на получение уведомлений об изменении содержимого каталогов. Для этого предназначена Windows-функция FindFirstChangeNotifica-tionили ReadDirectoryChangesW.B качестве входного параметра приложение указывает имя нужного каталога, и функция сообщает о любом изменении в содержимом этого каталога. Хотя этот подход более эффективен, чем сканирование тома, он требует непрерывной работы приложения. При этом приложениям все равно может понадобиться сканирование каталогов, так как FindFirstChangeNotificationсообщает лишь о факте изменений, а не о конкретных изменениях. B то же время ReadDirectoryChangesWпринимает от приложения буфер, который FSD заполняет записями об изменениях. Ho при переполнении буфера приложение должно быть готово вернуться к сканированию каталога.
NTFS предусматривает третий подход, в котором преодолены недостатки первых двух: приложение может настроить журнал изменений NTFS с помощью функции DeviceIoControlи управляющего кода FSCTL_CREATE_USNJOURNAL; тогда NTFS будет регистрировать информацию об изменениях файлов и каталогов во внутреннем файле – журнале изменений(change journal). Этот журнал обычно достаточно велик, что дает приложению шанс обработать все без исключения изменения. Для чтения записей в журнале изменений предназначен управляющий код FSCTL_QUERY_USNJOURNAL; при этом можно указать, чтобы функция DeviceIoControlне завершалась до тех пор, пока в журнале не появятся новые записи.
NTFS отслеживает использование тома благодаря тому факту, что помечает файлы и каталоги идентификаторами защиты (SID) пользователей, создавших эти объекты на томе (определение SID см. в главе 8). Сумма логических размеров файлов и каталогов, принадлежащих пользователю, сравнивается с квотой, определенной администратором. Поэтому пользователь не может превысить свою квоту, создав пустой разреженный файл и потом заполняя его ненулевыми значениями. Кстати, хотя 50-килобайтный файл может быть сжат до 10 Кб, при учете используется его исходный размер – 50 Кб.
По умолчанию отслеживание квот на томах отключено. Чтобы разрешить отслеживание квот, указать пороговые значения для выдачи предупреждений, задать ограничения и настроить реакцию NTFS на достижение одного из этих пороговых значений, используйте вкладку Quota (Квота) окна свойств тома (рис. 12-18). Диалоговое окно Quota Entries (Записи квот), которое можно открыть с этой вкладки, позволяет администратору задавать различные лимиты и поведение NTFS для каждого пользователя. Приложения, которым требуется управление на основе квот NTFS, используют СОМ-интерфейсы квот, в том числе IDiskQuotaControl, IDiskQuotaUserи IDiskQuotaEvents.
Аналогичным образом OLE-связи позволяют встраивать документы одних приложений в документы, созданные другими приложениями. OLE-связи поддерживаются всеми приложениями из пакета Microsoft Office, включая PowerPoint, Excel и Word.
Хотя OLE-связи дают возможность легко соединять файлы друг с другом и с пространством имен оболочки, управлять ими в прошлом было нелегко. Если пользователь Windows NT 4, Windows 95 или Windows 98 перемещал источник OLE-связи или ярлыка оболочки (источником называется файл или каталог, на который ссылается OLE-связь или ярлык), связь разрывалась, и система предпринимала попытку найти источник связи эвристическим методом. B Windows файловая система NTFS включает поддержку отслеживания распределенных связей (distributed link-tracking), обеспечивающую целостность ярлыков оболочки и OLE-связей при перемещении источников на другой том NTFS в пределах одного домена.
Отслеживание связей в NTFS реализуется на основе необязательного атрибута файла, известного под названием идентификатор объекта(object ID). Приложение может назначить такой идентификатор файлу с помощью управляющих кодов файловой системы FSCTL_CREATE_OR_GET_OBJECT_ID (назначает идентификатор, если он еще не назначен) и FSCTL_SET_OBJECT_ID. Идентификаторы объектов можно запросить с помощью управляющих кодов FSCTL_CREATE_OR_GET_OBJECT_ID и FSCTL_GET_OBJECT_ID. Код FSCTL_DELETE_OBJECT_ID позволяет удалять идентификаторы объектов из файлов.
NTFS поддерживает механизм Encrypting File System (EFS), с помощью которого пользователи могут шифровать конфиденциальные данные. EFS, как и механизм сжатия файлов, полностью прозрачен для приложений. Это означает, что данные автоматически расшифровываются при чтении их приложением, работающим под учетной записью пользователя, который имеет права на просмотр этих данных, и автоматически шифруются при изменении их авторизованным приложением.
ПРИМЕЧАНИЕ NTFS не допускает шифрования файлов, расположенных в корневом каталоге системного тома или в каталоге \Windows, поскольку многие находящиеся там файлы нужны в процессе загрузки, когда EFS еще не активна.
EFS использует криптографические сервисы, предоставляемые Windows в пользовательском режиме, и состоит из драйвера устройства режима ядра, тесно интегрированного с NTFS и DLL-модулями пользовательского режима, которые взаимодействуют с подсистемой локальной аутентификации (LSASS) и криптографическими DLL.
Доступ к зашифрованным файлам можно получить только с помощью закрытого ключа из криптографической пары EFS (которая состоит из закрытого и открытого ключей), а закрытые ключи защищены паролем учетной записи. Таким образом, без пароля учетной записи, авторизованной для просмотра данных, доступ к зашифрованным EFS файлам на потерянных или краденых портативных компьютерах нельзя получить никакими средствами (кроме грубого перебора паролей).
Windows-функции EncryptFileи DecryptFileпозволяют шифровать и дешифровать файлы, a FileEncryptionStatus –получать атрибуты файла или каталога, связанного с EFS, – например, чтобы определить, зашифрован ли данный файл или каталог.
Для упрощения разработки независимых средств дефрагментации дисков в Windows включен API дефрагментации, с помощью которого подобные утилиты могут перемещать файловые данные так, чтобы файлы занимали непрерывные кластеры. Этот API реализован на основе управляющих кодов файловой системы: FSCTL_GET_VOLUME_BITMAP (возвращает карту свободных и занятых кластеров тома), FSCTL_GET_RETRIEVAL_POINTERS (возвращает карту кластеров, занятых файлом) и FSCTL_MOVE_FILE (перемещает файл).
B Windows имеется встроенная программа дефрагментации, доступная через утилиту Disk Defragmenter (\Windows\System32\Dfrg.msc). Ей присущ ряд ограничений, в частности в Windows 2000 эту утилиту нельзя запускать из командной строки или автоматически запускать по заданному расписанию. B Windows XP и Windows Server 2003 у программы дефрагментации появился интерфейс командной строки, \Windows\System32\Defrag.exe, позволяющий запускать процесс дефрагментации интерактивно или по расписанию, но она по-прежнему не сообщает детальных отчетов и не поддерживает такие возможности, как исключение определенных файлов или каталогов из процесса дефрагментации. Сторонние утилиты дефрагментации дисков, как правило, предлагают более богатую функциональность.
B Windows XP поддержка дефрагментации для NTFS была переписана, чтобы снять часть ограничений, которые были в Windows 2000. Так, в Windows 2000 поддержка дефрагментации NTFS опиралась на диспетчер кэша, что создавало ряд ограничений, например невозможность перемещения файловых блоков размером более 256 Кб или дефрагментации файлов метаданных NTFS. (Заметьте, что 256 Кб – это размер представлений, поддерживаемых диспетчером кэша. Подробнее о диспетчере кэша см. главу 11.) B реализации дефрагментации NTFS в Windows XP и Windows Server 2003 существует лишь одно ограничение – нельзя дефрагментировать страничные файлы и файлы журналов NTFS.
Драйверы передают друг другу запросы ввода-вывода, вызывая диспетчер ввода-вывода исполнительной системы. Использование диспетчера ввода-вывода в качестве промежуточного звена обеспечивает независимость каждого драйвера, что позволяет загружать и выгружать его без последствий для других драйверов. Кроме того, драйвер NTFS взаимодействует с тремя другими компонентами исполнительной системы (рис. 12-21), тесно связанными с файловыми системами.
Сервис файла журнала (log file service, LFS) является частью NTFS и предоставляет функции для поддержки журнала изменений на диске. Файл журнала LFS используется при восстановлении тома NTFS в случае аварии системы (подробнее о LFS см. раздел «Сервис файла журнала» далее в этой главе).
Диспетчер кэша – компонент исполнительной системы, предоставляющий общесистемные сервисы кэширования для NTFS и драйверов других файловых систем, в том числе сетевых (т. е. для серверов и редиректоров). Все файловые системы, реализованные в Windows, получают доступ к кэшированным файлам, проецируя их на системное адресное пространство, а затем считывая соответствующие участки виртуальной памяти. C этой целью диспетчер кэша предоставляет диспетчеру памяти специализированный интерфейс файловых систем. Когда программа пытается обратиться к какой-либо части файла, не загруженной в кэш (промах кэша), диспетчер памяти вызывает NTFS для обращения к драйверу диска и загрузки нужных файловых данных. Диспетчер кэша оптимизирует дисковый ввод-вывод, вызывая диспетчер памяти (для сброса на диск содержимого кэша в фоновом режиме) из потоков подсистемы отложенной записи.
NTFS участвует в модели объектов Windows, реализуя файлы в виде объектов. Такая реализация допускает совместное использование файлов и их защиту диспетчером объектов, который управляет всеми объектами уровня исполнительной системы (о диспетчере объектов см. главу 3).
Приложение создает файлы и обращается к ним так же, как и к любым другим объектам Windows, – через описатели объектов. K тому времени, когда запрос ввода-вывода достигает NTFS, диспетчер объектов и система защиты уже убедились в наличии у вызывающего процесса прав на запрошенные им виды доступа к объекту «файл». Система защиты сравнила маркер доступа вызывающего процесса с элементами ACL этого объекта «файл» (подробнее об ACL см. главу 8), а диспетчер ввода-вывода преобразовал описатель файла в указатель на объект «файл». NTFS использует информацию из объекта «файл» для обращения к файлу на диске.
Ha рис. 12-22 показаны структуры данных, связывающие описатель файла со структурой файловой системы на диске.
NTFS получает адрес файла на диске из объекта «файл» по нескольким указателям. Как видно из рис. 12-22, объект «файл», представляющий один вызов системного сервиса для открытия файла, указывает на блок управления потоком данных(stream control block, SCB) для атрибута, который вызывающая программа пытается считать или записать. B нашем случае процесс открыл как безымянный атрибут данных, так и именованный поток (альтернативный атрибут данных) файла. SCB представляют отдельные атрибуты файла и содержат информацию о том, как искать конкретные атрибуты внутри файла. Все SCB файла указывают на общую структуру данных – блок управления файлом(file control block, FCB). FCB содержит указатель на запись файла в главной таблице файлов (MFT), о которой мы поговорим в следующем разделе.
Ha диске может быть один или несколько томов. NTFS обрабатывает каждый том независимо от других. Три примера конфигурации 150-мегабайтного жесткого диска показаны на рис. 12-23.
Том состоит из набора файлов и свободного пространства, оставшегося в данном разделе диска. B FAT том также содержит области, специально отформатированные для использования файловой системой. Ho в томе NTFS все данные файловой системы вроде битовых карт, каталогов и даже начального загрузочного кода хранятся как обычные файлы.
ПРИМЕЧАНИЕ У NTFS -TOMOB в Windows 2000 дисковый формат версии 3.0; в Windows XP и Windows Server 2003 в этот формат были внесены незначительные изменения, и теперь используется его версия 3.1. Номер версии тома хранится в файле метаданных IVolume.
Внутренне NTFS работает только с кластерами. (Однако NTFS инициирует низкоуровневые операции ввода-вывода на томе, выравнивая передаваемые данные по размеру сектора и подгоняя их объем под значение, кратное размеру секторов.) NTFS использует кластер как единицу выделения пространства для поддержания независимости от размера физического сектора. Это позволяет NTFS эффективно работать с очень большими дисками, используя кластеры большего размера, и поддерживать нестандартные диски с размером секторов, отличным от 512 байтов. Применение больших кластеров на больших томах уменьшает фрагментацию и ускоряет выделение свободного пространства за счет небольшого проигрыша в эффективности использования дискового пространства. Команда formatили оснастка Disk Management выбирает кластерный множитель в зависимости от размера тома, но это значение можно изменить.
NTFS адресуется к конкретным местам на диске, используя логические номера кластеров(logical cluster numbers, LCN). Для этого все кластеры на томе просто нумеруются по порядку – от начала до конца. Для преобразования LCN в физический адрес на диске NTFS умножает LCN на кластерный множитель и получает байтовое смещение от начала тома, воспринимаемое интерфейсом драйвера диска. Ha данные внутри файла NTFS ссылается по виртуальным номерам кластеров(virtual cluster numbers, VCN), нумеруя кластеры, которые принадлежат конкретному файлу (от 0 до m).VCN не обязательно должны быть физически непрерывными.
Главная таблица файлов (MFT) занимает центральное место в структуре NTFS-тома. MFT реализована как массив записей о файлах. Размер каждой записи фиксирован и равен 1 Кб (см. раздел «Записи о файлах» далее в этой главе). Логически MFT содержит по одной строке на каждый файл тома, включая строку для самой MFT Кроме MFT, на каждом томе NTFS имеется набор файлов метаданных с информацией, необходимой для реализации структуры файловой системы. Имена всех файлов метаданных NTFS начинаются со знака доллара ($), хотя эти знаки скрыты. Так, имя файла MFT – $Mft. Остальные файлы NTFS-тома являются обычными файлами и каталогами (рис. 12-24).
Обычно каждая запись MFT соответствует отдельному файлу Ho если у файла много атрибутов или он сильно фрагментирован, для него может понадобиться более одной записи. Тогда первая запись MFT, хранящая адреса других записей, называется
базовой(base file record).
ЭКСПЕРИМЕНТ: просмотр MFT
Утилита Nfi из OEM Support Tools (входит в отладочные средства Windows; ее можно скачать с support.mlcrosoft.com/support/eb/articIes/Q253/ 0/66.asp)позволяет получить дамп содержимого MFT тома NTFS и преобразовать номер кластера тома или номер сектора физического диска (не для RAID-томов) в имя соответствующего файла (если кластер или сектор занят файлом). Первые 16 элементов MFT зарезервированы для файлов метаданных, но записи для файлов необязательных метаданных (которые присутствуют только при использовании на томе соответствующих возможностей) находятся вне этой области: \$Extend\$Quota, \$Extend\$ObjId, \$Extend\$UsnJrnl и \$Extend\$Reparse. Следующий дамп получен для тома, на котором используются точки повторного разбора ($Reparse), квоты ($Quota) и идентификаторы объектов ($ObjId).
При первом обращении к тому NTFS должна смонтировать его, т. е. считать с диска метаданные и сформировать внутренние структуры данных, необходимые для обработки обращений к файловой системе. Чтобы смонтировать том, NTFS ищет в загрузочном секторе физический адрес MFT на диске. Запись о самой MFT является первым элементом в этой таблице, вторая запись указывает на файл в середине диска ($MftMirr), который называется зеркальной копией MFT и содержит копию первых нескольких записей MFT Если по каким-либо причинам считать часть MFT не удастся, для поиска файлов метаданных будет использована именно эта копия MFT.
Найдя запись для MFT, NTFS получает из ее атрибута данных информацию о сопоставлении VCN и LCN и сохраняет ее в памяти. B каждой группе (run) хранится сопоставление VCN-LCN и длина этой группы – вот и вся информация, необходимая для того, чтобы найти LCN по VCN. Эта информация сообщает NTFS, где на диске искать группы, образующие MFT (O группах см. раздел «Резидентные и нерезидентные атрибуты» далее в этой главе.) Затем NTFS обрабатывает записи MFT еще для нескольких файлов метаданных и открывает эти файлы. Наконец, NTFS выполняет операцию восстановления фаршовой системы (см. раздел «Восстановление» далее в этой главе) и открывает остальные файлы метаданных. C этого момента пользователь может обращаться к данному дисковому тому.
Процесс может запросить содержимое точки повторного разбора с помощью управляющего кода FSCTL_GET_REPARSE_POINT. B атрибутах файла, сопоставленного с точкой повторного разбора, присутствует флаг FILEAT-TRIBUTE_REPARSE_POINT, что позволяет приложениям проверять наличие точек повторного разбора вызовом Windows-функции GetFileAttributes.
ЭКСПЕРИМЕНТ: создание точки соединения
B Windows нет средств для создания точек соединения, но вы можете создать такую точку с помощью утилиты Junction ( wwwsysinternak.com )или Linkd из ресурсов Windows. Утилита Linkd позволяет просмотреть определения существующих точек соединения, a Junction – вывести информацию о точках соединения и точках повторного разбора.
Сжатие и разреженные файлы
NTFS поддерживает сжатие файловых данных. Поскольку NTFS выполняет процедуры сжатия и декомпрессии прозрачно, нет необходимости модифицировать приложения для того, чтобы они могли пользоваться преимуществами этой функции. Каталог также может быть сжат, что влечет за собой сжатие и тех файлов, которые будут впоследствии созданы в этом каталоге.Приложения сжимают и разархивируют файлы, передавая DeviceIoControlуправляющий код FSCTL_SET_COMPRESSION. Для запроса состояния сжатия файла или каталога используется управляющий код FSCTL_GET_COMPRES-SION. У сжатого файла или каталога установлен флаг FILE_ATTRIBUTE_COM-PRESSED, поэтому приложения могут определять состояние сжатия файла или каталога вызовом GetFileAttributes.
Второй тип сжатия известен под названием разреженные файлы(sparse files). Если файл помечен как разреженный, NTFS не выделяет на томе место для тех частей файла, которые определены приложением как пустые. При чтении приложением пустых областей разреженного файла NTFS просто возвращает буферы, заполненные нулевыми значениями. Этот тип сжатия полезен для клиент-серверных приложений, в которых реализовано протоколирование с циклическими буферами (circular-buffer logging): сервер регистрирует информацию в файле, а клиент асинхронно считывает ее. Поскольку информация, уже считанная клиентом, больше не нужна, продолжать хранить ее в файле не требуется. Если такой файл является разреженным, клиент может определять считанные им области как пустые, тем самым освобождая место на томе. A сервер может добавлять новую информацию в файл, не опасаясь, что он в конечном счете займет все свободное пространство на томе.
Как и в случае сжатых файлов, NTFS прозрачно управляет разреженными файлами. Приложения указывают состояние разреженности файла, передавая DeviceIoControlуправляющий код FSCTL_SET_SPARSE. Чтобы определить диапазон файла как пустой, приложения используют код FSCTL_SET_ 2ERO_DATA, а чтобы запросить у NTFS описание того, какие части файла являются разреженными, – код FSCTL_QUERY_ALLOCATED_RANGES. Разреженные файлы применяются, в частности, в журнале изменений NTFS, о котором мы расскажем в следующем разделе.
Протоколирование изменений
Приложениям многих типов нужно отслеживать изменения файлов и каталогов тома. Например, программа автоматического резервного копирования первоначально выполняет полное резервное копирование, а в дальнейшем копирует только измененные файлы. Очевидный способ мониторинга изменений тома – его сканирование с записью состояния файлов и каталогов и анализ отличий при следующем сканировании. Однако этот процесс может негативно повлиять на производительность системы – особенно на компьютерах, хранящих тысячи и десятки тысяч файлов.Альтернативный подход для приложения заключается в том, чтобы зарегистрироваться на получение уведомлений об изменении содержимого каталогов. Для этого предназначена Windows-функция FindFirstChangeNotifica-tionили ReadDirectoryChangesW.B качестве входного параметра приложение указывает имя нужного каталога, и функция сообщает о любом изменении в содержимом этого каталога. Хотя этот подход более эффективен, чем сканирование тома, он требует непрерывной работы приложения. При этом приложениям все равно может понадобиться сканирование каталогов, так как FindFirstChangeNotificationсообщает лишь о факте изменений, а не о конкретных изменениях. B то же время ReadDirectoryChangesWпринимает от приложения буфер, который FSD заполняет записями об изменениях. Ho при переполнении буфера приложение должно быть готово вернуться к сканированию каталога.
NTFS предусматривает третий подход, в котором преодолены недостатки первых двух: приложение может настроить журнал изменений NTFS с помощью функции DeviceIoControlи управляющего кода FSCTL_CREATE_USNJOURNAL; тогда NTFS будет регистрировать информацию об изменениях файлов и каталогов во внутреннем файле – журнале изменений(change journal). Этот журнал обычно достаточно велик, что дает приложению шанс обработать все без исключения изменения. Для чтения записей в журнале изменений предназначен управляющий код FSCTL_QUERY_USNJOURNAL; при этом можно указать, чтобы функция DeviceIoControlне завершалась до тех пор, пока в журнале не появятся новые записи.
Квоты томов, индивидуальные для каждого пользователя
Системным администраторам часто бывает нужно отслеживать или ограничивать дисковое пространство, занимаемое пользователями на общих томах в сети. Поэтому NTFS поддерживает управление дисковым пространством на основе квот, позволяя выделять квоты каждому пользователю. NTFS можно настроить на запись в системный журнал события, возникающего в тот момент, когда пользователь превышает пороговое значение, близкое к лимиту. При попытке пользователя занять больше места, чем разрешает его квота, NTFS также регистрирует соответствующее событие в системном журнале и, кроме того, завершает файловый ввод-вывод приложения, вызвавшего нарушение квоты, с кодом ошибки «disk full» («диск заполнен»).NTFS отслеживает использование тома благодаря тому факту, что помечает файлы и каталоги идентификаторами защиты (SID) пользователей, создавших эти объекты на томе (определение SID см. в главе 8). Сумма логических размеров файлов и каталогов, принадлежащих пользователю, сравнивается с квотой, определенной администратором. Поэтому пользователь не может превысить свою квоту, создав пустой разреженный файл и потом заполняя его ненулевыми значениями. Кстати, хотя 50-килобайтный файл может быть сжат до 10 Кб, при учете используется его исходный размер – 50 Кб.
По умолчанию отслеживание квот на томах отключено. Чтобы разрешить отслеживание квот, указать пороговые значения для выдачи предупреждений, задать ограничения и настроить реакцию NTFS на достижение одного из этих пороговых значений, используйте вкладку Quota (Квота) окна свойств тома (рис. 12-18). Диалоговое окно Quota Entries (Записи квот), которое можно открыть с этой вкладки, позволяет администратору задавать различные лимиты и поведение NTFS для каждого пользователя. Приложения, которым требуется управление на основе квот NTFS, используют СОМ-интерфейсы квот, в том числе IDiskQuotaControl, IDiskQuotaUserи IDiskQuotaEvents.
Отслеживание ссылок
B пространстве имен оболочки Windows (например, на рабочем столе) можно создавать ярлыки (shortcuts) файлов, находящихся в пространстве имен файловой системы. Такие ярлыки используются, например, в меню Start.Аналогичным образом OLE-связи позволяют встраивать документы одних приложений в документы, созданные другими приложениями. OLE-связи поддерживаются всеми приложениями из пакета Microsoft Office, включая PowerPoint, Excel и Word.
Хотя OLE-связи дают возможность легко соединять файлы друг с другом и с пространством имен оболочки, управлять ими в прошлом было нелегко. Если пользователь Windows NT 4, Windows 95 или Windows 98 перемещал источник OLE-связи или ярлыка оболочки (источником называется файл или каталог, на который ссылается OLE-связь или ярлык), связь разрывалась, и система предпринимала попытку найти источник связи эвристическим методом. B Windows файловая система NTFS включает поддержку отслеживания распределенных связей (distributed link-tracking), обеспечивающую целостность ярлыков оболочки и OLE-связей при перемещении источников на другой том NTFS в пределах одного домена.
Отслеживание связей в NTFS реализуется на основе необязательного атрибута файла, известного под названием идентификатор объекта(object ID). Приложение может назначить такой идентификатор файлу с помощью управляющих кодов файловой системы FSCTL_CREATE_OR_GET_OBJECT_ID (назначает идентификатор, если он еще не назначен) и FSCTL_SET_OBJECT_ID. Идентификаторы объектов можно запросить с помощью управляющих кодов FSCTL_CREATE_OR_GET_OBJECT_ID и FSCTL_GET_OBJECT_ID. Код FSCTL_DELETE_OBJECT_ID позволяет удалять идентификаторы объектов из файлов.
Шифрование
Корпоративные пользователи часто хранят на своих компьютерах конфиденциальную информацию. Хотя данные на серверах компаний обычно надежно защищены, информация, хранящаяся на портативном компьютере, может попасть в чужие руки в случае потери или кражи компьютера. Права доступа к файлам NTFS в таком случае не защитят данные, поскольку полный доступ к томам NTFS можно получить независимо от их защиты – достаточно воспользоваться программами, умеющими читать файлы NTFS вне среды Windows. Более того, права доступа к файлам NTFS становятся бесполезны при использовании другой системы Windows и учетной записи администратора. Вспомните из главы 8, что учетная запись администратора обладает привилегиями захвата во владение и резервного копирования, любая из которых позволяет получить доступ к любому защищенному объекту в обход его параметров защиты.NTFS поддерживает механизм Encrypting File System (EFS), с помощью которого пользователи могут шифровать конфиденциальные данные. EFS, как и механизм сжатия файлов, полностью прозрачен для приложений. Это означает, что данные автоматически расшифровываются при чтении их приложением, работающим под учетной записью пользователя, который имеет права на просмотр этих данных, и автоматически шифруются при изменении их авторизованным приложением.
ПРИМЕЧАНИЕ NTFS не допускает шифрования файлов, расположенных в корневом каталоге системного тома или в каталоге \Windows, поскольку многие находящиеся там файлы нужны в процессе загрузки, когда EFS еще не активна.
EFS использует криптографические сервисы, предоставляемые Windows в пользовательском режиме, и состоит из драйвера устройства режима ядра, тесно интегрированного с NTFS и DLL-модулями пользовательского режима, которые взаимодействуют с подсистемой локальной аутентификации (LSASS) и криптографическими DLL.
Доступ к зашифрованным файлам можно получить только с помощью закрытого ключа из криптографической пары EFS (которая состоит из закрытого и открытого ключей), а закрытые ключи защищены паролем учетной записи. Таким образом, без пароля учетной записи, авторизованной для просмотра данных, доступ к зашифрованным EFS файлам на потерянных или краденых портативных компьютерах нельзя получить никакими средствами (кроме грубого перебора паролей).
Windows-функции EncryptFileи DecryptFileпозволяют шифровать и дешифровать файлы, a FileEncryptionStatus –получать атрибуты файла или каталога, связанного с EFS, – например, чтобы определить, зашифрован ли данный файл или каталог.
Поддержка POSIX
Как говорилось в главе 2,одно из требований KWindows состояло в том, что она должна полностью поддерживать стандарт POSIX 1003.1 .Стандарт POSIX требует от файловой системы поддержки имен файлов и каталогов, чувствительных к регистру букв, цепочечных разрешений (traversal permissions) (для доступа к файлу нужны права на доступ к каждому каталогу на пути к этому файлу), метки времени изменения файла (отличной от метки времени последней модификации файла в MS-DOS) и жестких связей. Вся эта функциональность в NTFS реализована.Дефрагментация
Многие верят в то, что NTFS якобы автоматически оптимизирует размещение файлов на диске, не допуская их фрагментации. Хотя она стремится записывать файлы в непрерывные области, со временем файлы на томе могут стать фрагментированными – особенно когда свободного пространства мало. Файл является фрагментированным, если его данные занимают несмежные кластеры. Так, на рис. 12-19 показан фрагментированный файл, состоящий из трех фрагментов. Ho, как и большинство файловых систем (включая версию FAT в Windows), NTFS не предпринимает специальных мер по поддержанию непрерывного размещения файлов на диске – разве что резервирует область дискового пространства, называемую зоной главной таблицы файлов (master file table, MFT), где и хранится MFT (NTFS разрешает выделять место под файлы из зоны MFT, когда на томе остается мало свободного пространства.) Подробнее о MFT см. раздел «Главная таблица файлов» далее в этой главе.Фрагментированный файл Непрерывный файл
B Windows имеется встроенная программа дефрагментации, доступная через утилиту Disk Defragmenter (\Windows\System32\Dfrg.msc). Ей присущ ряд ограничений, в частности в Windows 2000 эту утилиту нельзя запускать из командной строки или автоматически запускать по заданному расписанию. B Windows XP и Windows Server 2003 у программы дефрагментации появился интерфейс командной строки, \Windows\System32\Defrag.exe, позволяющий запускать процесс дефрагментации интерактивно или по расписанию, но она по-прежнему не сообщает детальных отчетов и не поддерживает такие возможности, как исключение определенных файлов или каталогов из процесса дефрагментации. Сторонние утилиты дефрагментации дисков, как правило, предлагают более богатую функциональность.
B Windows XP поддержка дефрагментации для NTFS была переписана, чтобы снять часть ограничений, которые были в Windows 2000. Так, в Windows 2000 поддержка дефрагментации NTFS опиралась на диспетчер кэша, что создавало ряд ограничений, например невозможность перемещения файловых блоков размером более 256 Кб или дефрагментации файлов метаданных NTFS. (Заметьте, что 256 Кб – это размер представлений, поддерживаемых диспетчером кэша. Подробнее о диспетчере кэша см. главу 11.) B реализации дефрагментации NTFS в Windows XP и Windows Server 2003 существует лишь одно ограничение – нельзя дефрагментировать страничные файлы и файлы журналов NTFS.
Поддержка доступа только для чтения
До Windows XP драйвер файловой системы NTFS поддерживал монтирование тома исключительно на записываемом носителе, куда он должен был помещать файлы журналов транзакций. Драйверы NTFS в Windows XP и Windows Server 2003 могут монтировать тома на носителях только для чтения; эта функциональность нужна во встраиваемых системах, в которых базовые образы файловой системы (base file system images) доступны только для чтения.Драйвер файловой системы NTFS
Как отмечалось в главе 9, подсистема ввода-вывода Windows устроена так, что NTFS и другие файловые системы представляют собой загружаемые драйверы устройств режима ядра. Они неявно вызываются приложениями, использующими Windows или другие API ввода-вывода (например, POSIX). Как показано на рис. 12-20, подсистемы окружения вызывают системные сервисы, которые в свою очередь находят соответствующие загруженные драйверы и вызывают их. (O диспетчеризации системных сервисов см. раздел «Диспетчеризация системных сервисов» главы 3.)Диспетчер кэша – компонент исполнительной системы, предоставляющий общесистемные сервисы кэширования для NTFS и драйверов других файловых систем, в том числе сетевых (т. е. для серверов и редиректоров). Все файловые системы, реализованные в Windows, получают доступ к кэшированным файлам, проецируя их на системное адресное пространство, а затем считывая соответствующие участки виртуальной памяти. C этой целью диспетчер кэша предоставляет диспетчеру памяти специализированный интерфейс файловых систем. Когда программа пытается обратиться к какой-либо части файла, не загруженной в кэш (промах кэша), диспетчер памяти вызывает NTFS для обращения к драйверу диска и загрузки нужных файловых данных. Диспетчер кэша оптимизирует дисковый ввод-вывод, вызывая диспетчер памяти (для сброса на диск содержимого кэша в фоновом режиме) из потоков подсистемы отложенной записи.
NTFS участвует в модели объектов Windows, реализуя файлы в виде объектов. Такая реализация допускает совместное использование файлов и их защиту диспетчером объектов, который управляет всеми объектами уровня исполнительной системы (о диспетчере объектов см. главу 3).
Приложение создает файлы и обращается к ним так же, как и к любым другим объектам Windows, – через описатели объектов. K тому времени, когда запрос ввода-вывода достигает NTFS, диспетчер объектов и система защиты уже убедились в наличии у вызывающего процесса прав на запрошенные им виды доступа к объекту «файл». Система защиты сравнила маркер доступа вызывающего процесса с элементами ACL этого объекта «файл» (подробнее об ACL см. главу 8), а диспетчер ввода-вывода преобразовал описатель файла в указатель на объект «файл». NTFS использует информацию из объекта «файл» для обращения к файлу на диске.
Ha рис. 12-22 показаны структуры данных, связывающие описатель файла со структурой файловой системы на диске.
NTFS получает адрес файла на диске из объекта «файл» по нескольким указателям. Как видно из рис. 12-22, объект «файл», представляющий один вызов системного сервиса для открытия файла, указывает на блок управления потоком данных(stream control block, SCB) для атрибута, который вызывающая программа пытается считать или записать. B нашем случае процесс открыл как безымянный атрибут данных, так и именованный поток (альтернативный атрибут данных) файла. SCB представляют отдельные атрибуты файла и содержат информацию о том, как искать конкретные атрибуты внутри файла. Все SCB файла указывают на общую структуру данных – блок управления файлом(file control block, FCB). FCB содержит указатель на запись файла в главной таблице файлов (MFT), о которой мы поговорим в следующем разделе.
Структура NTFS на диске
Здесь мы рассмотрим структуру тома NTFS, включая способы разбиения дискового пространства и его организации в кластеры, принципы хранения на диске реальных файловых данных и информации об атрибутах, а также поясним, как работает механизм сжатия данных в NTFS.Тома
Структура NTFS начинается с тома. Том(volume) соответствует логическому разделу на диске и создается при форматировании диска или его части под NTFS. Оснастка Disk Management (Управление дисками) консоли MMC также позволяет создать том RAID, охватывающий несколько дисков.Ha диске может быть один или несколько томов. NTFS обрабатывает каждый том независимо от других. Три примера конфигурации 150-мегабайтного жесткого диска показаны на рис. 12-23.
ПРИМЕЧАНИЕ У NTFS -TOMOB в Windows 2000 дисковый формат версии 3.0; в Windows XP и Windows Server 2003 в этот формат были внесены незначительные изменения, и теперь используется его версия 3.1. Номер версии тома хранится в файле метаданных IVolume.
Кластеры
Размер кластера на томе NTFS, или кластерный множитель(cluster factor), устанавливается при форматировании тома командой formatили в оснастке Disk Management (Управление дисками). Размер кластера по умолчанию определяется размером тома, но всегда содержит целое число физических секторов с дискретностью N 2(т. е. 1 сектор, 2 сектора, 4 сектора, 8 секторов и т. д.). Кластерный множитель выражается числом байтов в кластере, например 512 байт, 1 Кб или 2 Кб.Внутренне NTFS работает только с кластерами. (Однако NTFS инициирует низкоуровневые операции ввода-вывода на томе, выравнивая передаваемые данные по размеру сектора и подгоняя их объем под значение, кратное размеру секторов.) NTFS использует кластер как единицу выделения пространства для поддержания независимости от размера физического сектора. Это позволяет NTFS эффективно работать с очень большими дисками, используя кластеры большего размера, и поддерживать нестандартные диски с размером секторов, отличным от 512 байтов. Применение больших кластеров на больших томах уменьшает фрагментацию и ускоряет выделение свободного пространства за счет небольшого проигрыша в эффективности использования дискового пространства. Команда formatили оснастка Disk Management выбирает кластерный множитель в зависимости от размера тома, но это значение можно изменить.
NTFS адресуется к конкретным местам на диске, используя логические номера кластеров(logical cluster numbers, LCN). Для этого все кластеры на томе просто нумеруются по порядку – от начала до конца. Для преобразования LCN в физический адрес на диске NTFS умножает LCN на кластерный множитель и получает байтовое смещение от начала тома, воспринимаемое интерфейсом драйвера диска. Ha данные внутри файла NTFS ссылается по виртуальным номерам кластеров(virtual cluster numbers, VCN), нумеруя кластеры, которые принадлежат конкретному файлу (от 0 до m).VCN не обязательно должны быть физически непрерывными.
Главная таблица файлов
B NTFS все данные, хранящиеся на томе, содержатся в файлах. Это относится и к структурам данных, используемым для поиска и выборки файлов, к начальному загрузочному коду и битовой карте, в которой регистрируется состояние пространства всего тома (метаданные NTFS). Хранение всех видов данных в файлах позволяет файловой системе легко находить и поддерживать данные, а каждый файл может быть защищен дескриптором защиты. Кроме того, при появлении плохих секторов на диске, NTFS может переместить файлы метаданных.Главная таблица файлов (MFT) занимает центральное место в структуре NTFS-тома. MFT реализована как массив записей о файлах. Размер каждой записи фиксирован и равен 1 Кб (см. раздел «Записи о файлах» далее в этой главе). Логически MFT содержит по одной строке на каждый файл тома, включая строку для самой MFT Кроме MFT, на каждом томе NTFS имеется набор файлов метаданных с информацией, необходимой для реализации структуры файловой системы. Имена всех файлов метаданных NTFS начинаются со знака доллара ($), хотя эти знаки скрыты. Так, имя файла MFT – $Mft. Остальные файлы NTFS-тома являются обычными файлами и каталогами (рис. 12-24).
ЭКСПЕРИМЕНТ: просмотр MFT
Утилита Nfi из OEM Support Tools (входит в отладочные средства Windows; ее можно скачать с support.mlcrosoft.com/support/eb/articIes/Q253/ 0/66.asp)позволяет получить дамп содержимого MFT тома NTFS и преобразовать номер кластера тома или номер сектора физического диска (не для RAID-томов) в имя соответствующего файла (если кластер или сектор занят файлом). Первые 16 элементов MFT зарезервированы для файлов метаданных, но записи для файлов необязательных метаданных (которые присутствуют только при использовании на томе соответствующих возможностей) находятся вне этой области: \$Extend\$Quota, \$Extend\$ObjId, \$Extend\$UsnJrnl и \$Extend\$Reparse. Следующий дамп получен для тома, на котором используются точки повторного разбора ($Reparse), квоты ($Quota) и идентификаторы объектов ($ObjId).
Найдя запись для MFT, NTFS получает из ее атрибута данных информацию о сопоставлении VCN и LCN и сохраняет ее в памяти. B каждой группе (run) хранится сопоставление VCN-LCN и длина этой группы – вот и вся информация, необходимая для того, чтобы найти LCN по VCN. Эта информация сообщает NTFS, где на диске искать группы, образующие MFT (O группах см. раздел «Резидентные и нерезидентные атрибуты» далее в этой главе.) Затем NTFS обрабатывает записи MFT еще для нескольких файлов метаданных и открывает эти файлы. Наконец, NTFS выполняет операцию восстановления фаршовой системы (см. раздел «Восстановление» далее в этой главе) и открывает остальные файлы метаданных. C этого момента пользователь может обращаться к данному дисковому тому.