Compartilhar via


Visão geral da API Bindlink

A biblioteca Bindlink permite que os usuários administradores vinculem um namespace do sistema de arquivos a um caminho virtual local por meio do Filtro de Ligação (bindflt.sys de minifiltro). Os Links de Ligação fornecem redirecionamento do sistema de arquivos de um caminho virtual local 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 vinculaçã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.

Uso

O conjunto de APIs é composto por 2 funções relacionadas:

  • CreateBindLink – Essa API permite que os administradores criem um link de ligação entre um caminho virtual e um caminho de suporte.
  • RemoveBindLink – Esta API permite que um usuário remova um link que foi criado anteriormente chamando CreateBindLink.

Para obter exemplos de uso dessas funções, consulte Bindlink examples.

Os links de ligação são transparentes para os aplicativos e, embora esses links existam, todas as operações se aplicam ao caminho de suporte. Como resultado, DeleteFile ou RemoveDirectory atuará sobre o caminho de suporte, 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, caso contrário, a api falhará com ERROR_ACCESS_DENIED.

Se um aplicativo tentar seguir o link para um caminho de backup que foi excluído após a configuração do link, o aplicativo verá ERROR_FILE_NOT_FOUND*. Mais tarde, se o caminho de suporte for criado novamente, o link será aplicado a esse novo caminho de backup. Se um arquivo fosse criado no virtualPath enquanto o link existe, ele apareceria no virtualPath se o link existir, mas for criado fisicamente no caminho de backup. Quando o link é removido, o arquivo só aparece no caminho de backup e não aparece mais no virtualPath. Isso se aplica a todos os tipos de links descritos abaixo.

Dependendo se o caminho virtual estiver presente no disco, o link resultante será um link sem âncora ou um link de sombra.

Links sem âncora são links de ligação que são criados quando o caminho virtual não existe no disco antes de o link ser criado. Quando esse tipo de link é criado, o caminho virtual é sintetizado na memória e aparece como um caminho normal no sistema de arquivos. Observe que, para criar esse link de ligação, o pai do caminho virtual deve existir como um diretório em 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 já não houvesse um volume chamado "Z".

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 suporte se torna visível no caminho virtual. Por exemplo:

  • C:\Foo existe no disco com dois arquivos Cat.txt e Dog.txt
  • C:\Bar existe no disco com dois arquivos Cow.txt e Mouse.txt

Quando um link é criado com C:\Foo como o caminho virtual e C:\Bar como o caminho de suporte, o caminho C:\Foo mostrará Cow.txt e Mouse.txt a todos os usuários enquanto Cat.txt e Dog.txt ficarão ocultos, até que o link seja removido.

Outro exemplo no diagrama a seguir ajuda a distinguir entre link de sombra e link sem âncora.

Anchorless versus shadow bind links diagram

Um usuário enumerando c:\Foo encontrará o diretório e seu conteúdo existente antes mesmo que qualquer um dos links de ligação mostrados no diagrama sejam criados. Depois que os links forem criados, enumerar c:\Foo mostrará C:\Foo\Bar e 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 suporte se aplicam.

Determinados sinalizadores podem ser passados para alterar o comportamento padrão para atender às necessidades do usuário.

Um link mesclado é como um link de sombra, exceto que o conteúdo existente no caminho virtual é mesclado com o caminho de suporte. Para criar esse tipo de link, o sinalizador CREATE_BIND_LINK_FLAG_MERGED deve ser usado.

Vamos considerar o exemplo anterior para shadow link mais uma vez, com a adição desta bandeira.

Por exemplo:

  • C:\Foo existe no disco com dois arquivos Cat.txt e Dog.txt
  • C:\Bar existe no disco com dois arquivos Cow.txt e Mouse.txt

Quando um link é criado com C:\Foo como o caminho virtual e C:\Bar como o caminho de backup com o sinalizador CREATE_BIND_LINK_FLAG_MERGED, o caminho C:\Foo mostrará Cat.txt, Dog.txt, Cow.txt e 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 a 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 arquivo foi criado no caminho mesclado quando o link mesclado existe, ele será criado fisicamente no backingPath (como é o caso de qualquer link de ligação) e substituirá um arquivo com o mesmo nome no virtualPath.

Vamos considerar as seguintes estruturas de diretório 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 mesclagem, c:\Foo\Sub mostrará apenas Bar_sub.txt. No entanto, se c:\Foo estiver vinculado a c:\Bar com mesclagem, c:\Foo\Sub mostrará Foo_sub.txt e Bar_sub.txt.

Como os links de associaçã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.

Links somente leitura são links de ligação em que os usuários no sistema são impedidos de fazer alterações em arquivos que residem no caminho de backup se forem acessados por meio do 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 arquivos que residem no caminho de backup no disco. Se o link for mesclado e os arquivos originalmente do caminho do diretório virtual estiverem visíveis, eles permanecerão modificáveis.

Por exemplo:

  • C:\Foo existe no disco com um arquivo Cat.txt
  • C:\Bar existe no disco com um arquivo Cow.txt

Quando um link é criado com C:\Foo como o caminho virtual e C:\Bar como o caminho de backup e o link é marcado como somente leitura e mesclado, Cat.txt e Cow.txt estarão visíveis em C:\Foo, no entanto, Cat.txt será modificável enquanto Cow.txt não será modificável.

Além disso, essa API oferece suporte a vários outros cenários de link. Elas estão descritas nas seções a seguir.

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.

Observe que não há restrição quanto aos links circulares subsequentes.

Nested bind links diagram

Considere os links e a ordem dos links no diagrama "Links de ligação aninhados" acima.

Se um link for criado com 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 existe no disco com um arquivo Cat.txt
  • C:\Target2 existe no disco com um arquivo Dog.txt
  • C:\Foo existe no disco com uma barra de diretórios

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 verá Dog.txt e a Barra de diretório, já que Bar é um caminho virtual para seu próprio link. Posteriormente, se C:\Foo\Bar\Baz estiver vinculado a C:\Target2 (Link3), um usuário enumerando c:\Foo\Bar verá Cat.txt e o diretório Baz, já que Baz é um caminho virtual para seu próprio link.

Os seguintes pontos são importantes e devem sempre ser considerados em conjunto ao decidir sobre o resultado de um link ou um conjunto de links:

  1. O caminho de suporte sempre tem precedência e substitui se uma entidade com os mesmos nomes existir no caminho virtual ou em virtude de um link. Isso se aplica a todos os tipos de Links de Vinculação.

    Por exemplo, considere o seguinte link:

    c:\Foo está vinculado a c:\Target, onde c:\Target é um arquivo.

    Nesse caso, c:\Foo se parecerá com um arquivo com conteúdo de c:\Target para um link sem âncora. 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.

  2. 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 links a seguir. O segundo link altera a exibição do namespace.

    • Link1: c:\Foo está vinculado a c:\Target, onde c:\Target é um diretório. c:\O destino tem uma barra de arquivos
    • Link2: c:\Foo\Bar está vinculado a c:\Target2, onde Target2 é um diretório que contém um arquivo Cat.txt

    Order of bind links diagram

    Nesse caso, depois que o Link1 for criado, c:\Foo terá uma barra de arquivos. No entanto, após Link2, c:\Foo mostrará uma barra de diretório com um arquivo 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 continuará a aparecer como um diretório mostrando Cat.txt de c:\Target2. O caminho de suporte tem precedência sobre os itens em um caminho virtual, mas eles não têm precedência sobre a raiz do caminho virtual em si.

    • Link1: c:\Foo\Bar está vinculado a c:\Target2, onde Target2 é um diretório que contém um arquivo Cat.txt
    • Link2: c:\Foo está vinculado a c:\Target, onde c:\Target é um diretório. c:\O destino tem uma barra de arquivos
  3. Para que um link seja criado com êxito, o pai do caminho virtual deve existir localmente ou estar aparecendo devido ao backingPath em um link anterior ou ser um caminho virtual em si em um link.

    Por exemplo, se c:\Foo estiver vinculado a c:\Target primeiro e, em seguida, c:\Foo\Bar\Baz estiver sendo vinculado a um caminho de suporte, 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 tiver uma barra de diretório) ou
    • c:\Foo\Bar é um caminho virtual em si em outro link (c:\Foo\Bar ==> algo)

    Observação

    Isso implica que os 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 de suporte. Portanto, a barra de diretório virtual aparece em c:\Foo e não em c:\Target. A tabela de links terá a seguinte aparência:

  • C:\Foo --> c:\Target, C:\Foo\Bar --> c:\Target2 e não
  • C:\Foo --> c:\Target, c:\Target\Bar --> c:\Target2

Opcionalmente, exceções podem ser especificadas para limitar o escopo do link criado. Os caminhos de exceção são descendentes do caminho virtual em que 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 estiver sendo criado. A exceção se aplica a todos os descendentes do caminho de exceção. Por exemplo:

  • C:\Foo existe no disco e contém uma barra de diretório e um diretório Baz
  • C:\Foo\Bar contém Cat.txt
  • C:\Foo\Baz contém Dog.txt
  • C:\Target existe no disco e contém um arquivo 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 conterá o arquivo Cow.txt de C:\Target e o diretório Baz com seu filho Dog.txt. Observe que C:\Foo\Bar não ficará visível, pois foi sombreado pelo link.

O diagrama a seguir representa o cenário descrito acima:

Bind link exceptions diagram

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.

Confira também

Funções Bindlink

Enums Bindlink

Exemplos de Bindlink