Перечисление CREATE_BIND_LINK_FLAGS (bindlink.h)
Эти флаги можно передать в CreateBindLink , чтобы изменить поведение ссылки привязки по умолчанию в соответствии с потребностями пользователя.
Синтаксис
typedef enum CREATE_BIND_LINK_FLAGS {
CREATE_BIND_LINK_FLAG_NONE,
CREATE_BIND_LINK_FLAG_READ_ONLY,
CREATE_BIND_LINK_FLAG_MERGED
} ;
Константы
CREATE_BIND_LINK_FLAG_NONE 0x00000000 Флаги связи привязки не указаны. |
CREATE_BIND_LINK_FLAG_READ_ONLY 0x00000001 Ссылки только для чтения — это ссылки привязки, в которых пользователи в системе не могут вносить изменения в файлы, находящиеся в резервном пути, если доступ к нему осуществляется через виртуальный путь. Это означает, что пользователь с разрешением на изменение файла в резервном пути по-прежнему может изменить этот файл, если он обращается к нему через резервный путь, но не по виртуальному пути. Как правило, разрешения резервного пути применяются при доступе к соответствующему виртуальному пути, однако при использовании флага READ_ONLY разрешения на запись маскируются. Это гарантирует, что приложения увидят, что файл READ_ONLY. Обратите внимание, что ограничение только для чтения применяется только к файлам, которые находятся по резервному пути на диске. Если ссылка будет объединена, а файлы, изначально полученные по пути к виртуальному каталогу, видны, они останутся измененными. Пример: C:\Foo существует на диске с файлом Cat.txt C:\Bar существует на диске с файлом Cow.txt Если ссылка создается с C:\Foo в качестве виртуального пути и C:\Bar в качестве резервного пути, а ссылка помечена как доступная только для чтения и объединена, Cat.txt и Cow.txt будут отображаться в C:\Foo, однако Cat.txt будет изменяться, а Cow.txt не будет изменяться. |
CREATE_BIND_LINK_FLAG_MERGED 0x00000002 Объединенная ссылка похожа на теневое соединение, за исключением того, что существующее содержимое в виртуальном пути объединяется с резервным путем. Давайте еще раз рассмотрим предыдущий пример для теневой ссылки с добавлением этого флага. Пример: — C:\Foo существует на диске с двумя файлами Cat.txt и Dog.txt — C:\Bar существует на диске с двумя файлами Cow.txt и Mouse.txt При создании ссылки с C:\Foo в качестве виртуального пути и C:\Bar в качестве резервного пути с флагом CREATE_BIND_LINK_FLAG_MERGED путь C:\Foo будет отображать Cat.txt, Dog.txt, Cow.txt и Mouse.txt. Обратите внимание, что объединенные ссылки применяются только в том случае, если виртуальный путь является каталогом. В случае, когда файл отображается как в резервном, так и в виртуальном пути, файл в резервном пути имеет приоритет (т. е. файл в виртуальном пути маскируется). Это рекурсивно применяется ко всем каталогам в виртуальном пути. Так как слияние применяется к каталогам, если virtualPath и backingPath имеют каталог с одинаковым именем на одном уровне, каталог будет объединен в качестве результата ссылки. Если ссылка не была объединенной, каталог в резервном пути будет иметь приоритет и переопределить каталог в virtualPath. Если файл был создан по объединенному пути, когда существует объединенная ссылка, он будет физически создан по резервному пути (как в случае с любой ссылкой привязки) и переопределит файл с тем же именем в virtualPath. Рассмотрим следующие структуры каталогов: — c:\Foo\Sub\Foo_sub.txt — c:\Bar\Sub\Bar_sub.txt И две разные ссылки: — {c:\Foo связан с c:\Bar WITHOUT merge}. В этом случае c:\Foo\Sub отображает только Bar_sub.txt. — {c:\Foo связан с c:\Bar WITH merge}. В этом случае c:\Foo\Sub будет отображать как Foo_sub.txt, так и Bar_sub.txt. Так как ссылки привязки являются ссылками на основе пути, при замене, изменении или удалении или повторном создании файла в резервном пути после создания ссылки виртуальный путь будет указывать на файл, который существует на момент перехода по ссылке. Это происходит потому, что ссылка разрешается при открытии файла. Соответственно, если файл из резервного пути маскировал файл в виртуальном пути из-за ссылки и файл в резервном пути был удален, последующий открытый файл откроется в виртуальном пути. |
Требования
Требование | Значение |
---|---|
Заголовок | bindlink.h |