Share via

Обзор API Bindlink

  • Статья

Библиотека Bindlink позволяет администраторам привязать пространство имен файловой системы к локальному виртуальному пути через фильтр привязки (мини-фильтр bindflt.sys). Привязка ссылок обеспечивает перенаправление файловой системы из локального виртуального пути к локальному или удаленному пути резервного копирования. Они могут в первую очередь включить два типа сценариев: во-первых, они могут создавать удаленные файлы через сетевую общую папку, что улучшает совместимость приложений, а во-вторых, позволяет сценариям, когда приложение хочет, чтобы файлы из разных расположений отображались в новом расположении, потенциально с разными именами и структурами каталогов, не копируя файлы. Привязка ссылок является прозрачной для приложений, и все существующие API работают без знания об этом перенаправлении. Для виртуального пути не создается физический файл или каталог, а ссылки привязки расширяют дескрипторы безопасности и разрешения файлов и каталогов в пути резервного копирования к виртуальному пути.

Использование

Набор API состоит из 2 связанных функций:

  • CreateBindLink — этот API позволяет администраторам создавать привязку между виртуальным путем и резервным путем.
  • RemoveBindLink — этот API позволяет пользователю удалить ссылку, созданную ранее путем вызова CreateBindLink.

Пример использования этих функций см . в примерах Bindlink.

Привязка ссылок является прозрачной для приложений и в то время как эти ссылки существуют, все операции применяются к резервному пути. В результате DeleteFile или RemoveDirectory будет действовать на основе резервного пути, эффективно удаляя обратный путь, но не ссылку. Этот API завершится ошибкой, если у пользователя нет прав Администратор istrator, если у пользователя нет разрешений на открытие виртуального пути или пути резервного копирования, если резервный путь не существует, если для виртуального пути существует другая ссылка, или если при настройке ссылки возникла внутренняя ошибка. В частности, пользователь администратора должен иметь возможность подключить фильтр (разрешения для FilterAttach), подключиться к порту фильтра (разрешения для Filter Подключение CommunicationPort) и получить доступ к корневому каталогу резервного пути или в противном случае api завершится сбоем с ERROR_ACCESS_DENIED.

Если приложение пытается перейти по ссылке на обратный путь, удаленный после настройки ссылки, приложение увидит ERROR_FILE_NOT_FOUND*. Позже, если резервный путь будет создан снова, ссылка будет применяться к этому новому пути резервной копии. Если файл должен был быть создан в virtualPath во время существования ссылки, он будет отображаться в virtualPath, если ссылка существует, но физически создается в пути резервного копирования. При удалении ссылки файл будет отображаться только в пути резервного копирования и больше не будет отображаться в virtualPath. Это относится ко всем типам ссылок, описанных ниже.

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

Ссылки без привязки — это привязки, созданные при наличии виртуального пути на диске перед созданием ссылки. При создании этой связи виртуальный путь синтезируется в памяти и отображается как обычный путь в файловой системе. Обратите внимание, что для создания такой привязки родительский элемент виртуального пути должен существовать как каталог на диске или как ранее созданная ссылка. Например, чтобы использовать C:\Foo\Bar в качестве виртуального пути, C:\Foo должен быть каталогом на диске или ранее созданным в качестве виртуального пути для другой ссылки. Так как для тома нет родительского элемента, нет привязки к тому, который не существует. Например, создание привязки с виртуальным путем "Z:" завершится ошибкой, если еще не было тома с именем "Z".

Теневая ссылка — это ссылка, в которой виртуальный путь существует на томе перед созданием ссылки. Если для создания ссылки используется такой виртуальный путь, содержимое виртуального пути скрыто, а содержимое резервного пути становится видимым на виртуальном пути. Например:

  • C:\Foo существует на диске с двумя файлами Cat.txt и Dog.txt
  • C:\Bar существует на диске с двумя файлами Cow.txt и Mouse.txt

Когда ссылка создается с помощью C:\Foo в качестве виртуального пути и C:\Bar в качестве резервного пути, путь C:\Foo будет отображать Cow.txt и Mouse.txt всем пользователям, пока Cat.txt и Dog.txt не будет скрыт, пока ссылка не будет удалена.

Другой пример на следующей схеме помогает различать теневой канал и связь без привязки.

Anchorless versus shadow bind links diagram

Пользователь, перечисляющий c:\Foo, найдет каталог и его существующее содержимое даже до создания любой из ссылок привязки, показанных на схеме. После создания ссылок перечисление c:\Foo отобразит C:\Foo\Bar и Cow.txt. Так как C:\Foo существует на диске со ссылкой или без нее, связь между C:\Foo и \\Remote\Target является теневой ссылкой.

Пользователь, перечисляющий c:\Foo, не увидит c:\Foo\Bar перед созданием второй ссылки привязки. Так как C:\Foo\Bar отображается только после добавления связи между c:\Foo\Bar и C:\Target2, это чисто виртуальная, поэтому связь между c:\Foo\Bar и C:\Target2 является безвязной ссылкой.

Обратите внимание, что для обоих типов ссылок применяются дескрипторы безопасности резервного пути.

Некоторые флаги можно передать, чтобы изменить поведение по умолчанию в соответствии с потребностями пользователя.

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

Рассмотрим предыдущий пример для теневой ссылки еще раз с добавлением этого флага.

Например:

  • C:\Foo существует на диске с двумя файлами Cat.txt и Dog.txt
  • C:\Bar существует на диске с двумя файлами Cow.txt и Mouse.txt

При создании ссылки с помощью C:\Foo в качестве виртуального пути и C:\Bar в качестве резервного пути с флагом CREATE_BIND_LINK_FLAG_MERGED, C:\Foo path будет отображать Cat.txt, Dog.txt, Cow.txt и Mouse.txt.

Важно помнить, что объединенные ссылки применяются только в том случае, если виртуальный путь является каталогом. В случае, когда файл отображается как в обратном пути, так и в виртуальном пути, файл в резервном пути имеет приоритет — т. е. файл в виртуальном пути маскируется. Это применяется рекурсивно для всех каталогов в виртуальном пути. Так как слияние применяется к каталогам, если virtualPath и backingPath имеют каталог с одинаковым именем на одном уровне, каталог будет объединен в качестве результата ссылки. Если ссылка не была объединенной ссылкой, каталог в backingPath будет иметь приоритет и переопределить каталог в virtualPath. Если файл был создан в объединенном пути при наличии объединенной ссылки, он будет физически создан в backingPath (как и в случае с любой привязкой) и переопределит файл с тем же именем в virtualPath.

Рассмотрим следующие структуры каталогов и две разные ссылки:

  • c:\Foo\Sub\Foo_sub.txt
  • c:\Bar\Sub\Bar_sub.txt.

Если c:\Foo связан с c:\Bar без слияния, то c:\Foo\Sub будет отображать только Bar_sub.txt. Однако если c:\Foo связан с c:\Bar с слиянием, то c:\Foo\Sub будет отображать как Foo_sub.txt, так и Bar_sub.txt.

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

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

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

Например:

  • C:\Foo существует на диске с файлом Cat.txt
  • C:\Bar существует на диске с файлом Cow.txt

При создании ссылки с помощью C:\Foo в качестве виртуального пути и C:\Bar в качестве пути резервного копирования, а ссылка помечена только для чтения и объединена, оба Cat.txt и Cow.txt будут отображаться в C:\Foo, однако Cat.txt будет изменяться, хотя Cow.txt не будет изменяться.

Кроме того, этот API поддерживает несколько других сценариев связывания. Они описаны в следующих разделах.

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

Обратите внимание, что нет ограничений на последующие циклические ссылки.

Nested bind links diagram

Рассмотрим ссылки и порядок ссылок на схеме вложенных привязываемых ссылок выше.

Если ссылка создается с виртуальным путем: C:\Foo\Bar, можно создать другую ссылку с помощью C:\Foo в качестве виртуального пути, а еще одну ссылку можно создать с помощью C:\Foo\Bar\Baz в качестве виртуального пути.

Например:

  • C:\Target существует на диске с файлом Cat.txt
  • C:\Target2 существует на диске с файлом Dog.txt
  • C:\Foo существует на диске с панелью каталогов

Если C:\Foo\Bar связан с C:\Target (Link1), а затем C:\Foo связан с C:\Target2 (Link2), пользователь, перечисляющий C:\Foo, увидит Dog.txt и панель каталогов, так как строка является виртуальным путем для собственной ссылки. Впоследствии, если C:\Foo\Bar\Baz связан с C:\Target2 (Link3), пользователь, перечисляющий c:\Foo\Bar, увидит Cat.txt и каталог Baz, так как Baz — это виртуальный путь для собственной ссылки.

Следующие моменты важны и всегда следует учитывать вместе при принятии решения о результатах ссылки или набора ссылок:

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

    Например, рассмотрим следующую ссылку:

    c:\Foo связан с c:\Target, где c:\Target — это файл.

    В этом случае c:\Foo будет выглядеть как файл с содержимым c:\Target для ссылки без привязки. Даже если c:\Foo является каталогом, который существует локально (теневая ссылка), указанная выше ссылка сделает c:\Foo похожим на файл, если ссылка и резервный путь существуют.

  2. В случае конфликтующих ссылок последний созданный канал имеет приоритет. Однако последняя ссылка не может скрыть предыдущий канал.

    В качестве другого примера рассмотрим следующие ссылки. Вторая ссылка изменяет представление пространства имен.

    • Link1: c:\Foo связан с c:\Target, где c:\Target является каталогом. c:\Target имеет панель файлов
    • Link2: c:\Foo\Bar связан с c:\Target2, где Target2 — это каталог, содержащий файл Cat.txt

    Order of bind links diagram

    В этом случае после создания Link1 в c:\Foo появится панель файлов. Однако после link2 c:\Foo отобразит панель каталогов с файлом Cat.txt. Аналогичным образом, если c:\Target2 был файлом, c:\Foo\Bar будет файлом с содержимым C:\Target2

    С другой стороны, если порядок ссылок был изменен, как показано ниже, c:\Foo\Bar будет продолжать отображаться как каталог, показывающий Cat.txt из c:\Target2. Резервный путь имеет приоритет над элементами под виртуальным путем, но они не имеют приоритета над корнем виртуального пути.

    • Link1: c:\Foo\Bar связан с c:\Target2, где Target2 является каталогом, содержащим файл Cat.txt
    • Link2: c:\Foo связан с c:\Target, где c:\Target является каталогом. c:\Target имеет панель файлов

  3. Для успешного создания ссылки родительский элемент виртуального пути должен существовать локально или отображаться из backingPath в предыдущей ссылке или быть виртуальным путем в ссылке.

    Например, если c:\Foo связан с c:\Target first, а затем c:\Foo\Bar\Baz связан с резервным путем, ссылка из c:\Foo\Bar\Baz будет выполнена успешно, если c:\Foo\Bar существует из-за одного из следующих условий:

    • c:\Foo\Bar существует локально, и исключение в предыдущей ссылке гарантирует, что c:\Foo\Bar не тенирован c:\Target (см. исключения в следующем разделе) или
    • c:\Foo\Bar существует в соответствии с предыдущей ссылкой (например, если c:\Target имеет панель каталогов) или
    • c:\Foo\Bar — это виртуальный путь в другой ссылке (c:\Foo\Bar ==> что-то)

    Примечание.

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

Рассмотрим следующие ссылки, созданные в том же порядке:

  • C:\Foo связан с C:\Target
  • C:\Foo\Bar связан с c:\Target2

Создание ссылки не влияет на поведение резервного пути. Поэтому панель виртуального каталога отображается в c:\Foo, а не в c:\Target. Таблица ссылок будет выглядеть следующим образом:

  • C:\Foo --> c:\Target, C:\Foo\Bar --> c:\Target2 и не
  • C:\Foo --> c:\Target, c:\Target\Bar --> c:\Target2

При необходимости можно указать исключения, чтобы ограничить область созданной ссылки. Пути исключений являются потомками виртуального пути, в котором ссылка не применяется. Пути исключений могут быть файлами или каталогами, но должны быть потомками виртуального пути. API-интерфейсы требуют, чтобы пути исключений были доступны при создании ссылки. Исключение применяется ко всем потомкам пути исключения. Например:

  • C:\Foo существует на диске и содержит панель каталогов и каталог Baz
  • C:\Foo\Bar содержит Cat.txt
  • C:\Foo\Baz содержит Dog.txt
  • C:\Target существует на диске и содержит файл Cow.txt

Если ссылка создается из C:\Foo на C:\Target с исключением C:\Foo\Baz, пользователь увидит следующее:

  • C:\Foo будет содержать файл Cow.txt из C:\Target, а каталог Baz со своим дочерним Dog.txt. Обратите внимание, что C:\Foo\Bar не будет видимым, так как он был затенен ссылкой.

На следующей схеме представлен сценарий, описанный выше:

Bind link exceptions diagram

Наконец, исключения привязки ссылок не применяются к безвязным ссылкам, так как без привязки виртуальные пути не имеют потомков по определению и, следовательно, не имеют путей, которые соответствуют требованиям. API вернет ошибку, если есть попытка передать исключения в бессвязную ссылку.

См. также

Функции Bindlink

Перечисления bindlink

Примеры bindlink