Visão geral da API Bindlink
A biblioteca Bindlink permite que os utilizadores administrativos vinculem um namespace de sistema de arquivos a um caminho local virtual por meio do Filtro de Enlace (mini filtro bindflt.sys). Os Links de Ligação fornecem redirecionamento do sistema de arquivos de um caminho local virtual para um caminho de backup local ou remoto. Eles podem habilitar principalmente dois tipos de cenários: primeiro, eles podem fazer com que arquivos remotos em um compartilhamento de rede pareçam locais, o que melhora a compatibilidade do aplicativo, e segundo, eles permitem cenários em que um aplicativo deseja que arquivos de locais diferentes apareçam em um novo local, potencialmente com nomes e estruturas de diretório diferentes, sem copiar os arquivos. Os links de ligação são transparentes para os aplicativos e todas as APIs existentes funcionam sem o conhecimento desse redirecionamento. Nenhum arquivo físico ou diretório é criado para o caminho virtual e os links de ligação estendem os descritores de segurança e as permissões dos arquivos e diretórios no caminho de backup para o caminho virtual.
Utilização
O conjunto de APIs é composto por 2 funções relacionadas:
- CreateBindLink – Esta API permite que os administradores criem um link entre um caminho virtual e um caminho de apoio.
- RemoveBindLink – Esta API permite que um usuário remova um link que foi criado anteriormente chamando CreateBindLink.
Para exemplos de uso dessas funções, consulte exemplos de Bindlink.
Criando links de ligação
Os links de ligação são transparentes para as aplicações e, embora estes links existam, todas as operações se aplicam ao caminho subjacente. Como resultado, DeleteFile ou RemoveDirectory atuará sobre o caminho de backup, excluindo efetivamente o caminho de backup, mas não o link. Essa API falhará se o usuário não tiver privilégios de administrador, se o usuário não tiver permissões para abrir o caminho virtual ou o caminho de backup, se o caminho de backup não existir, se existir outro link para o caminho virtual ou se houver uma falha interna durante a configuração do link. Especificamente, o usuário administrador deve ser capaz de anexar o filtro (permissões para FilterAttach), conectar-se à porta do filtro (permissões para FilterConnectCommunicationPort) e acessar a raiz do caminho de backup ou então a api falhará com ERROR_ACCESS_DENIED.
Se um aplicativo tentar seguir o link para um caminho de backup que foi excluído depois que o link foi configurado, o aplicativo verá ERROR_FILE_NOT_FOUND*. Mais tarde, se o caminho de origem for criado novamente, o link será aplicado a esse novo caminho de origem. Se um arquivo fosse criado no virtualPath enquanto o link existisse, ele apareceria no virtualPath se o link existe, mas é fisicamente criado no caminho de backup. Quando o link é removido, o arquivo só aparece no caminho de backup e não aparece mais no virtualPath. Isto aplica-se a todos os tipos de links descritos abaixo.
Dependendo se o caminho virtual está presente no disco, o link resultante será um link sem âncora ou um link de sombra.
Links sem âncora
Links sem âncora são links de ligação que são criados quando o caminho virtual não existe no disco antes que o link seja criado. Quando esse tipo de link é criado, o caminho virtual é sintetizado na memória e aparece como um caminho regular no sistema de arquivos. Observe que, para criar esse link de ligação, o pai do caminho virtual deve existir como um diretório no disco ou como um link criado anteriormente. Por exemplo, para usar C:\Foo\Bar como um caminho virtual, C:\Foo deve ser um diretório no disco ou criado anteriormente como o caminho virtual para outro link. Como não há pai para um volume, não pode haver um link sem âncora para um volume que não existe. Por exemplo, a criação de um link de ligação com um caminho virtual "Z:" falharia se ainda não houvesse um volume chamado "Z".
Links ocultos
Um link de sombra é aquele em que o caminho virtual existe no volume antes do link ser criado. Quando esse caminho virtual é usado para criar um link, o conteúdo do caminho virtual fica oculto enquanto o conteúdo do caminho de backup se torna visível no caminho virtual. Por exemplo:
- C:\Foo exists on disk with two files Cat.txt and Dog.txt
- C:\Bar exists on disk with two files Cow.txt and Mouse.txt
Quando um link é criado com C:\Foo como o caminho virtual e C:\Bar como o caminho de backup, o C:\Foo path will then show Cow.txt and Mouse.txt to all users while Cat.txt and Dog.txt ficará oculto, até que o link seja removido.
Outro exemplo no diagrama a seguir ajuda a distinguir entre link de sombra e link sem âncora.
Um usuário enumerando c:\Foo encontrará o diretório e seu conteúdo existente antes mesmo de qualquer um dos links de ligação mostrados no diagrama serem criados. Depois que os links forem criados, enumerar c:\Foo mostrará C:\Foo\Bar and Cow.txt. Como C:\Foo existe no disco com ou sem o link, o link entre C:\Foo e \\Remote\Target é um link de sombra.
Um usuário enumerando c:\Foo não veria c:\Foo\Bar antes que o segundo link de ligação fosse criado. Como C:\Foo\Bar aparece somente depois que o link entre c:\Foo\Bar e C:\Target2 é adicionado, é puramente virtual e, portanto, o link entre c:\Foo\Bar e C:\Target2 é um link sem âncora.
Observe que, para ambos os tipos de links, os descritores de segurança do caminho de backup se aplicam.
Certos sinalizadores podem ser passados para alterar o comportamento padrão para atender às necessidades do usuário.
CREATE_BIND_LINK_FLAG_MERGED sinalizador
Um link mesclado é como um link de sombra, exceto que o conteúdo existente no caminho virtual é mesclado com o caminho de backup. Para criar este tipo de link, o flag CREATE_BIND_LINK_FLAG_MERGED deve ser usado.
Vamos considerar novamente o exemplo anterior para shadow link, com a adição deste sinalizador.
Por exemplo:
- C:\Foo exists on disk with two files Cat.txt and Dog.txt
- C:\Bar exists on disk with two files Cow.txt and Mouse.txt
Quando um link é criado com C:\Foo como o caminho virtual e C:\Bar como o caminho de suporte com o sinalizador CREATE_BIND_LINK_FLAG_MERGED, C:\Foo path will show Cat.txt, Dog.txt, Cow.txt and Mouse.txt.
É importante lembrar que os links mesclados só se aplicam quando o caminho virtual é um diretório. No caso em que um arquivo aparece no caminho de backup e no caminho virtual, o arquivo no caminho de backup tem precedência – ou seja, o arquivo no caminho virtual é mascarado. Isso se aplica recursivamente para todos os diretórios dentro do caminho virtual. Como a mesclagem se aplica a diretórios, se o virtualPath e o backingPath tiverem um diretório com o mesmo nome no mesmo nível, o diretório será mesclado como resultado do link. Se o link não for um link mesclado, o diretório no backingPath terá precedência e substituirá o diretório no virtualPath. Se um ficheiro for criado no caminho unificado quando o vínculo unificado existir, ele será fisicamente criado no backingPath (como é o caso de qualquer vínculo) e substituirá um ficheiro com o mesmo nome no virtualPath.
Vamos considerar as seguintes estruturas de diretórios e os dois links diferentes:
- C:\Foo\Sub\Foo_sub.txt
- C:\Bar\Sub\Bar_sub.txt.
Se c:\Foo estiver vinculado a c:\Bar sem a fusão de, então c:\Foo\Sub will only show Bar_sub.txt. Contudo, se c:\Foo estiver vinculado a c:\Bar com a fusão, então c:\Foo\Sub will show both Foo_sub.txt and Bar_sub.txt.
Como os links de ligação são links baseados em caminho, se um arquivo for substituído, modificado ou excluído/recriado no caminho de backup depois que o link for criado, o caminho virtual apontará para o arquivo existente no momento em que o link estiver sendo seguido. Isso acontece porque o link é resolvido no momento em que um arquivo é aberto. Assim, se um arquivo do caminho de backup estava mascarando um arquivo no caminho virtual devido ao link, e se o arquivo no caminho de backup foi excluído, uma solicitação subsequente para abrir o arquivo o abrirá no caminho virtual.
CREATE_BIND_LINK_FLAG_READ_ONLY sinalizador
Links somente leitura são links de ligação em que os usuários do sistema são impedidos de fazer alterações em arquivos que residem no caminho de backup se forem acessados pelo caminho virtual. Isso significa que um usuário com permissão para modificar um arquivo no caminho de backup ainda pode modificar esse arquivo se acessá-lo pelo caminho de backup, mas não se acessá-lo pelo caminho virtual. Normalmente, as permissões do caminho de backup se aplicam como tal quando o caminho virtual correspondente é acessado, no entanto, quando CREATE_BIND_LINK_FLAG_READ_ONLY sinalizador é usado, as permissões de gravação são mascaradas. Isso garante que os aplicativos vejam que o arquivo está CREATE_BIND_LINK_FLAG_READ_ONLY.
Observe que a restrição somente leitura só se aplica a ficheiros que residem no caminho subjacente no disco. Se o link for fundido e os ficheiros originalmente do caminho do diretório virtual estiverem visíveis, continuarão a ser modificáveis.
Por exemplo:
- C:\Foo exists on disk with a file Cat.txt
- C:\Bar exists on disk with a file Cow.txt
Quando um link é criado com C:\Foo como o caminho virtual, C:\Bar as the backing path and the link is marked read-only and merged, both Cat.txt and Cow.txt será visível em C:\Foo, however, Cat.txt will be modifiable while Cow.txt, mas não será modificável.
Além disso, essa API suporta vários outros cenários de link. Estes são descritos nas secções seguintes.
Links aninhados
Os links de ligação podem ser aninhados. Isso significa que um ancestral ou um componente descendente de um caminho virtual também pode ser um caminho virtual para seu próprio link.
Note-se que não existe qualquer restrição quanto às ligações circulares subsequentes.
Considere os links e a ordem dos links no diagrama "Links de ligação aninhados" acima.
Se um link for criado com o caminho virtual: C:\Foo\Bar, outro link poderá ser criado com C:\Foo como seu caminho virtual, e ainda outro link poderá ser criado com C:\Foo\Bar\Baz como seu caminho virtual.
Por exemplo:
- C:\Target exists on disk with a file Cat.txt
- C:\Target2 exists on disk with a file Dog.txt
- C:\Foo existe no disco com uma barra de diretório
Se C:\Foo\Bar estiver vinculado a C:\Target (Link1) e, em seguida, C:\Foo estiver vinculado a C:\Target2 (Link2), um usuário enumerando C:\Foo will see Dog.txt e a barra de diretório, já que Bar é um caminho virtual para seu próprio link. Subsequentemente, se C:\Foo\Bar\Baz estiver vinculado a C:\Target2 (Link3), um usuário enumerando c:\Foo\Bar will see Cat.txt e o diretório Baz, já que Baz é um caminho virtual para seu próprio link.
Cenários adicionais de link de ligação
Os seguintes pontos são importantes e devem ser sempre considerados em conjunto ao decidir sobre o resultado de uma ligação ou de um conjunto de ligações:
O caminho de apoio sempre tem precedência e substitui se uma entidade com o mesmo nome existir no caminho virtual ou devido a um link. Isso se aplica a todos os tipos de links de ligação.
Por exemplo, considere o seguinte link:
c:\Foo está vinculado a c:\Target, onde c:\Target é um arquivo.
Nesse caso, o c:\Foo irá aparentar ser um ficheiro com o conteúdo de c:\Target, funcionando como um link sem ponto de referência. Mesmo que c:\Foo seja um diretório que existe localmente (link de sombra), o link acima fará com que c:\Foo pareça um arquivo se o link e o caminho de backup existirem.
No caso de links conflitantes, o link criado mais recentemente tem precedência. No entanto, o link mais recente não pode ocultar um link anterior.
Como outro exemplo, considere os seguintes links. O segundo link altera a exibição do namespace.
- Link1: c:\Foo está vinculado a c:\Target, onde c:\Target é um diretório. c:\Target tem uma barra de arquivos
- Link2: c:\Foo\Bar está ligado a c:\Target2, where Target2 is a directory containing a file Cat.txt
Nesse caso, depois que o Link1 for criado, c:\Foo terá uma barra de arquivos. No entanto, após Link2, c:\Foo will show a directory Bar with a file Cat.txt. Da mesma forma, se c:\Target2 fosse um arquivo, c:\Foo\Bar seria um arquivo com o conteúdo de C:\Target2
Por outro lado, se a ordem dos links foi invertida como mostrado abaixo, c:\Foo\Bar will continue to appear as a directory showing Cat.txt de c:\Target2. O caminho de apoio tem precedência sobre os itens de um caminho virtual, mas não tem precedência sobre a raiz do próprio caminho virtual.
- Link1: c:\Foo\Bar está ligado a c:\Target2, where Target2 is a directory containing a file Cat.txt
- Link2: c:\Foo está vinculado a c:\Target, onde c:\Target é um diretório. c:\Target tem uma barra de arquivos
Para que uma ligação seja criada com êxito, o pai do caminho virtual deve existir localmente ou estar a aparecer devido ao backingPath numa ligação anterior ou ser um caminho virtual em si próprio numa ligação.
Por exemplo, se c:\Foo estiver ligado a c:\Target primeiro e, em seguida, c:\Foo\Bar\Baz estiver a ser ligado a um caminho de apoio, o link de c:\Foo\Bar\Baz será bem-sucedido se c:\Foo\Bar existir devido a uma das seguintes condições:
- c:\Foo\Bar existe localmente e uma exceção no link anterior garante que c:\Foo\Bar não foi sombreado por c:\Target (consulte Exceções na próxima Seção) ou
- c:\Foo\Bar existe em virtude do link anterior (ou seja, se c:\Target tem uma barra de diretório) ou
- c:\Foo\Bar é por si só um caminho virtual em outro link (c:\Foo\Bar ==> algo).
Observação
Isso implica que links aninhados sem âncora devem ser criados com o link mais profundo sendo criado por último. No entanto, os links de sombra não têm essas restrições, pois os caminhos virtuais já existem no disco.
Considere os seguintes links criados na mesma ordem:
- C:\Foo está vinculado a C:\Target
- C:\Foo\Bar está vinculado a c:\Target2
A criação de um link não tem efeito sobre o comportamento do caminho base. Assim, a barra de diretório virtual aparece em c:\Foo e não em c:\Target. A tabela de links terá esta aparência:
- C:\Foo --> c:\Target, C:\Foo\Bar --> c:\Target2 e não
- C:\Foo --> c:\Target, c:\Target\Bar --> c:\Target2
Exceções para vincular links
Opcionalmente, exceções podem ser especificadas para limitar o escopo do link criado. Os caminhos de exceção são descendentes do caminho virtual onde o link não se aplica. Os caminhos de exceção podem ser arquivos ou diretórios, mas devem ser descendentes do caminho virtual. As APIs exigem que os caminhos de exceção estejam acessíveis quando o link está sendo criado. A exceção aplica-se a todos os descendentes do caminho de exceção. Por exemplo:
- C:\Foo existe no disco e contém um diretório Bar e um diretório Baz
- C:\Foo\Bar contains Cat.txt
- C:\Foo\Baz contains Dog.txt
- C:\Target exists on disk and contains a file Cow.txt
Se um link for criado de C:\Foo para C:\Target com uma exceção para C:\Foo\Baz, o usuário verá o seguinte:
- C:\Foo will contain the file Cow.txt de C:\Target, and the directory Baz with its child Dog.txt. Observe que C:\Foo\Bar não será visível, pois foi sombreado pelo link.
O diagrama a seguir representa o cenário descrito acima:
Finalmente, as exceções de link de ligação não se aplicam a links sem âncora, uma vez que os caminhos virtuais sem âncora não têm descendentes por definição e, portanto, não têm caminhos que se qualifiquem. A API retornará um erro se houver uma tentativa de passar exceções para o link sem âncora.