Четыре вида метаданных NTFS

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

    Речь пойдёт о точках повторной обработки (reparse points), идентификаторах объектов (object id) и о других типах данных, которые может содержать файл помимо своего основного содержимого.

    Object Id


    Идентификатор объекта это 64 байта, которые можно прикрепить к файлу или каталогу. Из них первые 16 байт позволяют однозначно идентифицировать файл в пределах тома и обращаться к нему не по имени, а по идентификатору. Остальные 48 байт могут содержать произвольные данные.

    Идентификаторы объектов существуют в NTFS со времён Windows 2000. В самой системе они используются для отслеживания расположения файла, на который ссылается ярлык (.lnk). Допустим, файл, на который ссылается ярлык, был перемещён в пределах тома. При запуске ярлыка он всё равно откроется. Специальная служба Windows в случае, если файл не найден, произведёт попытку открыть файл не по его имени, а по заранее созданному и сохранённому идентификатору. Если файл не был удалён и не покидал пределы тома, он откроется, а ярлык снова будет указывать на файл.

    Идентификаторы объектов использовались в технологии iSwift Антивируса Касперского 7-ой версии. Вот как описана эта технология: Технология разработана для файловой системы NTFS. В этой системе каждому объекту присваевается NTFS-индентификатор. Этот индентификатор сравнивается с значениями специальной базы данных iSwift. Если значения базы данных с NTFS-индентификатором не совпадают, то объект проверяется или перепроверяется, если он был изменен.

    Впрочем, переизбыток созданных идентификаторов вызывал проблемы со сканированием диска стандартной утилитой проверки chkdsk, она происходила слишком долго. В следующих версиях Антивируса Касперского отказались от использования NTFS Object Id.

    Reparse Point


    В файловой системе NTFS файл или каталог может содержать в себе reparse point, что переводится на русский язык как «точка повторной обработки». В файл или каталог добавляются специальные данные, файл перестаёт быть обычным файлом и обработать его может только специальный драйвер фильтра файловой системы.
    Символьная ссылка изнутри
    В Windows присутствуют типы reparse point, которые могут быть обработаны самой системой. Например, через точки повторной обработки в Windows реализуются символьные ссылки (symlink) и соединения (junction point), а также точки монтирования томов в каталог (mount points).
    Reparse-буфер, присоединяемый к файлу это буфер, имеющий максимальный размер 16 килобайт. Он характеризуется наличием тега, который говорит системе о том, к какому типу принадлежит точка повторной обработки. При использовании reparse-буфера собственного типа ещё необходимо задавать в нём GUID в специальном поле, а в reparse-буферах Microsoft он может отсутствовать.

    Какие типы точек повторной обработки существуют? Перечислю технологии, в которых используются reparse point'ы. Это Single Instance Storage (SIS) и Cluster Shared Volumes в Windows Storage Server 2008 R2, Hierarchical Storage Management, Distributed File System (DFS), Windows Home Server Drive Extender. Это технологии Microsoft, здесь не упомянуты технологии сторонних компаний, использующие точки повторной обработки, хотя такие тоже есть.

    Extended Attributes


    Расширенные атрибуты файла. Про них был мой предыдущий топик. Здесь стоит упомянуть только то, что под Windows эта технология практически не применяется. Из известного мне программного обеспечения только Cygwin использует расширенные атрибуты для хранения POSIX прав доступа. У одного файла на NTFS могут быть или расширенные атрибуты, или буфер точки повторной обработки. Одновременная установка и того и другого невозможна. Максимальный размер всех расширенных атрибутов у одного файла составляет 64 Кб.

    Alternate Data Streams


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

    Использовались в технологии iStream Антивируса Касперского. Используются в самой Windows, например при скачивании файла из интернета к нему прицепляется поток Zone.Identifier, содержащий информацию о том, из какого места получен данный файл. После запуска исполняемого файла пользователь может увидеть сообщение «Не удаётся проверить издателя. Вы действительно хотите запустить эту программу?».

    Так пользователю даётся дополнительная защита от необдуманного запуска программ, полученных из интернета. Это лишь одно применение потоков, а так в них можно хранить самые разные данные. Упомянутый Антивирус Касперского хранил там контрольные суммы каждого файла, но позже от этой технологии тоже по какой-то причине отказались.

    Что-нибудь ещё?


    Есть ещё идентификатор безопасности, плюс стандартные атрибуты файла, к которым нет прямого доступа, несмотря на то, что они тоже реализованы как потоки файлов. И они, и расширенные атрибуты, и reparse и object id — всё это потоки файла с точки зрения системы. Напрямую изменять идентификатор безопасности, показанный на следующей картинке как ::$SECURITY_DESCRIPTOR смысла нет, пусть его изменением занимается система. К другим типам потоков сама система не даёт прямого доступа. Так что на этом всё.

    Просмотр содержимого object id, точек повторной обработки, а также работа с расширенными атрибутами и альтернативными файловыми потоками возможна с помощью программы NTFS Stream Explorer, а также через системную консольную утилиту fsutil.

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 13

      +3
      Интересно было бы послушать про особенности файловых систем, скользких мест и.т.д. Может, напишите цикл небольшой? А то этот пост немного рассказывает, хотелось бы больше.
        +11
        Я могу написать про то же самое, но уже с точки зрения программирования. То есть какими API-функциями управляются эти метаданные, как выглядят структуры, как правильно формировать буферы и т.п. Про расширенные атрибуты у меня уже был пост, а про Object ID'ы и Reparse Points, пожалуй, можно будет написать по посту.
          +2
          Да, пожалуйста напишите. Думаю многим будет интересно и мне тоже.
            +2
            Да, напишите, пожалуйста.
              0
              да, было бы вообще интересно почитать про низкоуровневую работу с файловой системой)
                0
                Поддерживаю!
            +1
            Можно подробнее об отказе от NTFS Object ID в последующих версих Антивируса Касперского? Вот тут технология iSwift описана теми же самыми словами: support.kaspersky.ru/faq/?qid=208636752
            Версия довольно новая.
              +2
              Вот здесь они описывают суть проблемы и упоминают о том, что в 8-й версии собираются изменить механизм работы iSwift. Я наблюдал за работой KIS 2011, при включенном iSwift никаких Object Id'ов не создаётся. При обзоре форумов видно, что сообщения о проблеме датируются 2008-м годом. Значит, проблема была исправлена после этого срока. Скорее всего (не берусь утвержать точно), вместо Object Id'ов теперь там применяются другие идентификаторы файла, которые не требуется создавать, а которые уже изначально имеются у каждого файла на NTFS, возможно это IndexNumber из структуры FILE_INTERNAL_INFORMATION.
              0
              amdf, у Вас уже несколько статей по внутренностям NTFS.

              А вот представьте, я делаю небольшой раздел, например, 100 Мб. Затем форматирую его в NTFS, создаю на нём несколько директорий, пишу несколько файлов разного размера, играюсь с правами на файлы. Затем перегружаюсь в Linux и копирую командой dd весь NTFS раздел в файл. Затем образ NTFS раздела переношу в Windows, запускаю MS Viusal Studio С++, делаю mapping NTFS образа в память и…

              Собственно говоря, мне нужно реализовать следующие функции: open, read, write, close, lseek, chdir, opendir, readdir, closedir, mkdir, remove, rmdir.

              Иными словами, есть непреодолимое желание поработать с образом NTFS напрямую, без использования операционной системы.

              Вопросы: Насколько реально? С чего начать? Где взять документацию на NTFS?

              p.s. Использовать реализацию NTFS из ядра Linux по некоторым соображениям невозможно.

                +1
                Можно не из ядра, можно ntfs-3g, которая на FUSE.
                  +1
                  Можно смотреть исходники NTFS-3G, ещё можно посмотреть исходники NTFS Progs gnuwin32.sourceforge.net/packages/ntfsprogs.htm

                  Как минимум, разобраться со структурами и пробовать ими манипулировать.

                  Ещё можно почитать вот это: www.insidepro.com/kk/044/044r.shtml там в конце практическоая иллюстрация техники разбора файловой записи NTFS «руками».
                  0
                  Ещё можно почитать вот это: www.insidepro.com/kk/044/044r.shtml там в конце практическоая иллюстрация техники разбора файловой записи NTFS «руками».


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

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое