Войти
Точка повторной обработки NTFS является типом файловой системы NTFS объект. Он доступен с NTFS v3.0 в Windows 2000 или более поздних версиях. Точки повторной обработки позволяют расширить файловую систему NTFS. Точка повторной обработки содержит тег повторной обработки и данные, которые интерпретируются фильтром файловой системы, идентифицированным этим тегом. Microsoft включает несколько тегов по умолчанию, включая символические ссылки NTFS, точки соединения каталогов, точки монтирования тома и сокеты домена Unix. Кроме того, точки повторной обработки используются в качестве заполнителей для файлов, перемещаемых иерархической системой хранения Remote Storage Windows 2000. Они также могут действовать как жесткие ссылки, но не ограничиваются указанием файлов на том же томе: они могут указывать на каталоги на любом локальном томе. Эта функция унаследована от ReFS.
. Драйвер NTFS-3G с открытым исходным кодом реализует встроенную поддержку точек повторной обработки типа ссылок, а именно символических ссылок и точек соединения. Для обработки дополнительных типов точек повторной обработки доступна система фильтрации плагинов, позволяющая читать файлы с дедуплицированными фрагментами, файлы, сжатые системой, и файлы OneDrive.
Точка повторной обработки имеет следующую общую структуру в форме структуры C:
struct REPARSE_BUFFER {uint32_t ReparseTag; uint32_t ReparseDataLength; uint16_t Зарезервировано; uint8_t DataBuffer; // гибкий член массива}Тег повторной обработки уникален для каждого типа точки повторной обработки. Он определяет, какому обработчику точки повторной обработки (обычно это драйвер фильтра файловой системы) диспетчер ввода-вывода делегирует обработку. Microsoft предоставляет документацию по некоторым «общедоступным» типам тегов.
Точки монтирования тома аналогичны Unix mount указывает, где корень другой файловой системы присоединяется к каталогу. В NTFS это позволяет монтировать дополнительные файловые системы, не требуя отдельной буквы диска (например, C:или D:) для каждой из них.
После того, как том был смонтирован поверх существующего каталога другого тома, содержимое, ранее указанное в этом каталоге, становится невидимым и заменяется содержимым корневого каталога смонтированного тома. Подключенному тому по-прежнему может быть присвоена собственная буква диска. Файловая система не позволяет подключать тома друг к другу. Точки монтирования тома могут быть либо постоянными (перемонтируются автоматически после перезагрузки системы), либо непостоянными (необходимо перемонтировать вручную после перезагрузки).
Подключенные тома могут использовать другие файловые системы, кроме NTFS, возможно, со своими собственными настройки безопасности и переназначение прав доступа согласно политике удаленной файловой системы.
Заменяющие имена точек монтирования тома используют форму пространства имен NT \ ?? \ DeviceName \. В соединениях обычно используется \ ?? \ для ссылки на том с существующей буквой драйвера, в то время как истинные точки подключения тома используют \ ?? \ Volume {для ссылки на любой том. Пути UNC недопустимы для соединений.
Соединения каталогов определяются с использованием того же механизма (и тега повторной обработки: IO_REPARSE_TAG_MOUNT_POINT), что и точки монтирования тома. Единственное отличие состоит в том, что их замещающие имена указывают на подкаталог другого тома, который обычно уже имеет букву диска. Эта функция концептуально аналогична символическим ссылкам на каталоги в Unix, за исключением того, что целью в NTFS всегда должен быть другой каталог (типичные файловые системы Unix допускают, чтобы целью символической ссылки был файл любого типа).
Например, каталог C: \ exampledirс атрибутом соединения каталогов, который содержит ссылку на D: \ connecteddir, автоматически будет ссылаться на каталог D: \ connecteddir, когда к нему обращается приложение пользовательского режима.
Соединения каталогов (которые могут быть созданы с помощью команды MKLINK / J junctionName targetDirectoryи удалены с помощью RMDIR junctionNameиз приглашения консоли) являются постоянными и разрешаются на стороне сервера, поскольку они используют ту же область безопасности локальной системы или домена, на котором смонтирован родительский том, и те же параметры безопасности для его содержимого, что и содержимое целевого каталога; однако само соединение может иметь различные настройки безопасности. Удаление связи с соединением каталогов не приводит к удалению файлов в целевом каталоге.
Некоторые соединения каталогов устанавливаются по умолчанию в Windows Vista для совместимости с предыдущими версиями Windows, например Documents and Settingsв корневом каталоге системного диска, который ссылается на Пользователифизический каталог в корневом каталоге того же тома. Однако по умолчанию они скрыты, а их параметры безопасности настроены таким образом, что проводник Windows откажется открывать их из оболочки или в большинстве приложений, за исключением локального встроенного пользователя SYSTEM или локальной группы администраторов (оба пользователя учетные записи используются установщиками системного программного обеспечения). Это дополнительное ограничение безопасности, вероятно, было сделано для того, чтобы пользователи не могли найти очевидные дубликаты файлов в объединенных каталогах и удалить их по ошибке, потому что семантика соединений каталогов отличается от семантики жестких ссылок; подсчет ссылок не используется в целевом содержимом и даже в самом указанном контейнере.
Соединения каталогов - это мягкие ссылки (они будут сохраняться, даже если целевой каталог будет удален), работающие как ограниченная форма символического ссылки (с дополнительным ограничением на расположение цели), но это оптимизированная версия, позволяющая быстрее обрабатывать точку повторной обработки, с которой они реализованы, с меньшими накладными расходами, чем новые символические ссылки NTFS, и может быть разрешена на сервере сторона (когда они находятся в удаленных общих каталогах).
Символические ссылки (или программные ссылки) были введены в Windows Vista. Символические ссылки разрешаются на стороне клиента. Таким образом, когда символическая ссылка является общей, цель подчиняется ограничениям доступа на клиенте, а не на сервере.
Символьные ссылки могут быть созданы либо для файлов (созданных с помощью MKLINK symLink targetFilename) или в каталоги (созданные с помощью MKLINK / D symLinkD targetDirectory), но (в отличие от символических ссылок Unix) семантика ссылки должна обеспечиваться созданной ссылкой. Однако цель не обязательно должна существовать или быть доступной при создании символической ссылки: когда будет осуществлен доступ к символической ссылке и цель будет проверена на доступность, NTFS также проверит, имеет ли она правильный тип (файл или каталог); он вернет ошибку «не найден», если существующая цель имеет неправильный тип.
Они также могут ссылаться на общие каталоги на удаленных хостах или файлы и подкаталоги в общих каталогах: их цель не монтируется сразу при загрузке, но только временно по запросу при их открытии с помощью API OpenFile ()или CreateFile (). Их определение сохраняется на томе NTFS, где они созданы (все типы символических ссылок могут быть удалены, как если бы они были файлами, с помощью DEL symLinkиз командной строки или пакета).
Данные символической ссылки аналогичны данным точки монтирования, поскольку оба используют путь пространства имен NT. Разница в том, что символические ссылки принимают пути UNC, но не монтируют том {guid}.
Отслеживание распределенных ссылок позволяет приложениям отслеживать файлы, ярлыки оболочки или ссылки OLE, даже если они были переименованы или перемещены на другой том внутри того же компьютера, домена или рабочей группы. Отслеживание реализовано как системная служба, которая использует индекс идентификатора объекта (OID), хранящийся в метафайле. Когда приложение запрашивает дорожку в файле или каталоге, служба отслеживания создает запись OID, которая указывает на файл, а операция переименования, копирования или перемещения файла на том NTFS v3 также копирует идентификатор объекта. Это позволяет службе отслеживания в конечном итоге найти целевой файл.
Когда есть несколько каталогов с разными, но похожими файлами, некоторые из этих файлов могут иметь идентичное содержимое. Одноэкземплярное хранилище, которое можно найти в Windows Server 2000 - Windows Storage Server 2008, позволяет объединять идентичные файлы в один файл и создавать ссылки на этот объединенный файл. SIS состоит из фильтра файловой системы, который управляет копиями, модификацией и слиянием с файлами; и служба пользовательского пространства (или Groveler), которая ищет файлы, которые идентичны и нуждаются в слиянии. SIS в основном была разработана для серверов удаленной установки, поскольку на них может быть несколько установочных образов, содержащих много идентичных файлов; SIS позволяет их объединять, но, в отличие, например, от жестких ссылок, каждый файл остается отдельным; изменения одной копии файла оставят без изменений другие. Это похоже на копирование при записи, которое представляет собой метод, при котором копирование памяти не выполняется до тех пор, пока не будет изменена одна копия.
Начиная с Windows Server 2012, существует новый фрагмент механизм дедупликации данных (тег 0x80000013), который позволяет дедуплицировать файлы с похожим содержимым, если они содержат участки идентичных данных. Этот механизм более мощный, чем SIS. Начиная с Windows Server 2019, эта функция полностью поддерживается в ReFS.
Hierarchical Storage Management - это средство передачи файлов, которые не используются в течение некоторого периода времени, на менее дорогие носители. При следующем доступе к файлу точка повторной обработки этого файла определяет, что он необходим, и извлекает его из хранилища.
NSS было ActiveX технология хранения документов, которая с тех пор прекращена Microsoft. Это позволило хранить документы ActiveX в том же многопотоковом формате, который ActiveX использует для внутренних целей. Был загружен фильтр файловой системы NSS, который использовался для прозрачной обработки нескольких потоков для приложения, а когда файл передавался на дисковый том, не отформатированный в NTFS, он также переводил несколько потоков в один поток.
В Windows 10 build 17063 (для стабильной версии 1803) Microsoft представила доменные сокеты Unix для Windows, они реализованы с помощью драйвера ядра afunix.sys и новой точки повторной обработки в файловой системе. Доменные сокеты Unix распространены в системах BSD и Linux с давних пор и могут рассматриваться как стандарт для межпроцессного взаимодействия в этих системах. Поэтому их внедрение в Windows позволит упростить внедрение кода и кроссплатформенную переносимость.
Windows 10 представляет несколько алгоритмов сжатия только для чтения для NTFS, взятых из Windows Imaging Формат. Это XPRESS4K / 8K / 16K и LZX. Оба основаны на LZ77 с энтропийным кодированием Хаффмана, которого не хватало в LZNT1. В основном они используются для новой функции CompactOS, которая сжимает весь системный раздел с помощью одного из этих алгоритмов. Их также можно вручную включить для каждого файла с помощью флага / exeкоманды compact. Алгоритмы разделяют файлы на куски с поведением фрагментации, аналогичным обычному сжатию NTFS.
Внутренне файл записывается как точка повторной обработки с тегом 0x80000017 для записи того факта, что файл был специально сжат, а фактические данные сохраняются в альтернативном потоке данных с именем «WofCompressedData» (для Windows Overlay Файловая система). Новый дизайн предназначен исключительно для доступа только для чтения, поэтому любая запись в сжатые файлы приводит к полной распаковке файла в Windows.
OneDrive помечает файлы и каталоги, в которые он загрузил локальное хранилище как точка повторной обработки с тегом 0x9000001a. Фактические данные хранятся нормально.
Stuxnet как часть своей серии эксплойтов Win32 использует точки соединения NTFS как часть его общий режим работы.
