Vue d’ensemble de l’API Bindlink
La bibliothèque Bindlink permet aux utilisateurs administrateurs de lier l'espace de noms d'un système de fichiers à un chemin virtuel local via le Filtre d'association (mini-filtre bindflt.sys). Les liens d'association fournissent une redirection du système de fichiers à partir d’un chemin virtuel local vers un chemin de stockage local ou distant. Ils peuvent principalement donner lieu à deux types de scénarios : premièrement, faire apparaître comme locaux des fichiers qui sont en réalité distants sur un réseau partagé, ce qui améliore la compatibilité des applications ; et deuxièmement, permettre qu'une application puisse faire en sorte que des fichiers provenant de différents emplacements apparaissent dans un nouvel emplacement, potentiellement avec des noms et des structures de répertoires différents, sans pour autant les copier. Les liens d'association sont transparents pour les applications et toutes les API existantes travaillent sans avoir connaissance de cette redirection. Aucun fichier ou répertoire physique n'est créé pour le chemin d'accès virtuel et les liens d'association étendent les descripteurs de sécurité et les autorisations des fichiers et des répertoires du chemin de stockage au chemin d'accès virtuel.
Utilisation
L’ensemble des API est composé de 2 fonctions associées :
- CreateBindLink – Cette API permet aux administrateurs de créer un lien d'association entre un chemin d’accès virtuel et un chemin de stockage.
- RemoveBindLink – Cette API permet à un utilisateur de supprimer un lien précédemment créé en appelant CreateBindLink.
Pour obtenir des exemples d’utilisation de ces fonctions, consultez Exemples de Bindlink.
Création de liens d'association
Les liens d'association sont transparents pour les applications et, tant qu'ils existent, toutes les opérations s’appliquent au chemin de stockage. Par conséquent, DeleteFile ou RemoveDirectory agit sur le chemin de stockage, en supprimant effectivement celui-ci, mais pas le lien. Cette API échoue si l’utilisateur n’a pas de privilèges d’administrateur, si l’utilisateur n’a pas les autorisations nécessaires pour ouvrir le chemin d'accès virtuel ou le chemin de stockage, si le chemin de stockage n’existe pas, s’il existe un autre lien pour le chemin d’accès virtuel, ou encore s’il se produit une défaillance interne lors de la configuration du lien. Plus précisément, l’utilisateur administrateur doit être en mesure d’attacher le filtre (autorisations pour FilterAttach), de se connecter au port du filtre (autorisations pour FilterConnectCommunicationPort) et d’accéder à la racine du chemin de stockage. Dans le cas contraire, l’API échoue en raison d'une erreur ERROR_ACCESS_DENIED.
Si une application tente de suivre le lien vers un chemin de stockage qui a été supprimé après la configuration du lien, il se produit une erreur ERROR_FILE_NOT_FOUND*. Si par la suite, un nouveau chemin de stockage est créé, le lien s’applique à celui-ci. Si un fichier doit être créé dans le virtualPath tandis que le lien existe, il s’affiche dans le virtualPath, mais il est physiquement créé dans le chemin de stockage. Lorsque le lien est supprimé, le fichier n'apparaît plus que dans le chemin de stockage et ne s’affiche plus dans le virtualPath. Cela s’applique à tous les types de liens décrits ci-dessous.
Selon que le chemin d'accès virtuel est présent ou non sur le disque, le lien résultant sera un lien sans ancrage ou un lien fantôme.
Liens sans ancrage
Les liens sans ancrage sont des liens d'association qui sont créés à un moment où le chemin d'accès virtuel n’existe pas sur le disque. Lorsque ce type de lien est créé, le chemin d’accès virtuel est synthétisé en mémoire et apparaît comme un chemin d'accès normal dans le système de fichiers. Notez que pour créer un tel lien d'association, le parent du chemin d’accès virtuel doit exister soit en tant que répertoire sur le disque, soit en tant que lien précédemment créé. Par exemple, pour pouvoir utiliser C:\Foo\Bar comme chemin d’accès virtuel, C:\Foo doit être un répertoire sur le disque ou il doit avoir été créé auparavant en tant que chemin d’accès virtuel pour un autre lien. S'il n'y a pas de parent pour un volume, il ne peut pas y avoir de lien sans ancrage vers un volume qui n’existe pas. Par exemple, la création d’un lien d'association avec un chemin d’accès virtuel « Z: » échoue s’il n’y a encore aucun volume nommé « Z ».
Liens fantômes
Un lien fantôme correspond au cas où le chemin d'accès virtuel existe sur le volume avant le lien qui est créé. Lorsqu'un tel chemin d'accès virtuel est utilisé pour créer un lien, ses contenus sont masqués, tandis que ceux du chemin de stockage deviennent visibles dans le chemin d'accès virtuel. Par exemple :
- C:\Foo existe sur le disque, et contient deux fichiers Cat.txt et Dog.txt
- C:\Bar existe sur le disque, et contient deux fichiers Cow.txt et Mouse.txt
Si un lien est créé avec C:\Foo comme chemin d’accès virtuel et C:\Bar comme chemin de stockage, le chemin C:\Foo affichera Cow.txt et Mouse.txt à tous les utilisateurs, tandis que Cat.txt et Dog.txt seront masqués, et ce, jusqu'à ce que le lien soit supprimé.
Le diagramme suivant montre un autre exemple qui permet de faire la distinction entre un lien fantôme et un lien sans ancrage.
Un utilisateur énumérant C:\Foo trouvera le répertoire et ses contenus avant même la création de l’un des liens d'association affichés dans le diagramme. Une fois les liens créés, l’énumération C:\Foo affichera C:\Foo\Bar et Cow.txt. Étant donné que C:\Foo existe sur le disque, avec ou sans lien, le lien entre C:\Foo et \\Remote\Target est un lien fantôme.
Un utilisateur énumérant C:\Foo ne verra pas C:\Foo\Bar tant que le second lien d'association ne sera pas créé. Étant donné que C:\Foo\Bar n'apparaît qu'après l'ajout du lien entre C:\Foo\Bar et C:\Target2, il est purement virtuel. Le lien entre C:\Foo\Bar et C:\Target2 est donc un lien sans ancrage.
Notez que, pour ces deux types de liens, les descripteurs de sécurité du chemin de stockage s’appliquent.
Certains indicateurs peuvent être utilisés pour modifier le comportement par défaut afin de l'adapter aux besoins de l’utilisateur.
Indicateur CREATE_BIND_LINK_FLAG_MERGED
Un lien fusionné est semblable à un lien fantôme, sauf que le contenu existant dans le chemin d'accès virtuel est fusionné avec le chemin de stockage. Pour créer ce type de lien, il faut utiliser l’indicateur CREATE_BIND_LINK_FLAG_MERGED.
Reprenons une fois de plus l’exemple du lien fantôme précédent, auquel nous ajoutons cet indicateur.
Par exemple :
- C:\Foo existe sur le disque, et contient deux fichiers Cat.txt et Dog.txt
- C:\Bar existe sur le disque, et contient deux fichiers Cow.txt et Mouse.txt
Si un lien est créé avec C:\Foo comme chemin d’accès virtuel et C:\Bar comme chemin de stockage avec l'indicateur CREATE_BIND_LINK_FLAG_MERGED, le chemin C:\Foo affichera Cat.txt, Dog.txt, Cow.txt et Mouse.txt.
Il est important de préciser que les liens fusionnés ne s’appliquent que lorsque le chemin d’accès virtuel est un répertoire. Dans le cas où un fichier apparaît à la fois dans le chemin de stockage et le chemin d’accès virtuel, le fichier contenu dans le chemin de stockage est prioritaire, ce qui signifie que le fichier du chemin d’accès virtuel est masqué. Cela s’applique de manière récursive à tous les répertoires présents au sein du chemin d’accès virtuel. Étant donné que la fusion s’applique à des répertoires, si le virtualPath et le backingPath ont tous deux un répertoire portant le même nom et situé au même niveau, le lien entraînera la fusion des répertoires. Si le lien n’avait pas été un lien fusionné, le répertoire dans le chemin de stockage aurait été prioritaire et aurait remplacé le répertoire dans le virtualPath. Si un fichier est créé dans le répertoire fusionné lorsque le lien fusionné existe, il est physiquement créé dans le backingPath (tout comme avec n’importe quel lien d'association) et remplace tout fichier éventuel portant le même nom dans le virtualPath.
Considérons les structures de répertoire suivantes et les deux types de liens :
- c:\Foo\Sub\Foo_sub.txt
- c:\Bar\Sub\Bar_sub.txt.
Si C:\Foo est lié à C:\Bar sans fusion, C:\Foo\Sub affiche uniquement Bar_sub.txt. En revanche, si C:\Foo est lié à C:\Bar avec fusion, C:\Foo\Sub affiche à la fois Foo_sub.txt et Bar_sub.txt.
Étant donné que les liens d'association sont des liens basés sur des chemins d'accès, si un fichier est remplacé, modifié ou supprimé/recréé dans le chemin de stockage après la création du lien, le chemin d’accès virtuel pointe vers le fichier qui existe au moment où le lien est suivi. La raison en est que le lien est résolu au moment où un fichier est ouvert. En conséquence, si l'on supprime un fichier du chemin de stockage qui masquait un fichier dans le chemin d’accès virtuel du fait de l'existence du lien, toute requête ultérieure d’ouverture de ce fichier l’ouvrira dans le chemin d’accès virtuel.
Indicateur CREATE_BIND_LINK_FLAG_READ_ONLY
Les liens en lecture seule sont des liens d'association qui empêchent les utilisateurs système d'apporter des modifications aux fichiers qui résident dans le chemin de stockage et sont accessibles via le chemin d’accès virtuel. Cela signifie qu'un utilisateur autorisé à modifier un fichier dans le chemin de stockage peut toujours le modifier s’il y accède via le chemin de stockage, mais pas via le chemin d’accès virtuel. Normalement, les autorisations du chemin de stockage s’appliquent lorsque le chemin virtuel correspondant est accessible, mais si l'on utilise l'indicateur CREATE_BIND_LINK_FLAG_READ_ONLY, les autorisations d'écriture sont masquées. Cela garantit que les applications voient que le fichier est CREATE_BIND_LINK_FLAG_READ_ONLY.
Notez que la restriction en lecture seule ne s’applique qu'aux seuls fichiers qui résident dans le chemin de stockage sur le disque. Si le lien est fusionné et que les fichiers qui proviennent initialement du chemin d’accès virtuel sont visibles, ils restent modifiables.
Par exemple :
- C:\Foo existe sur le disque et contient un fichier Cat.txt
- C:\Bar existe sur le disque et contient un fichier Cow.txt
Si un lien est créé avec C:\Foo comme chemin d’accès virtuel et C:\Bar comme chemin de stockage, et que le lien est marqué en lecture seule et fusionné, les deux fichiers Cat.txt et Cow.txt seront visibles dans C:\Foo, mais seul Cat.txt sera modifiable (pas Cow.txt).
En outre, cette API prend en charge plusieurs autres options de lien. Elles sont décrites dans les sections suivantes.
Liens imbriqués
Les liens d'association peuvent être imbriqués. Cela signifie qu'un composant ancêtre ou descendant d’un chemin d’accès virtuel peut également être un chemin virtuel pour son propre lien.
Notez qu'il n’existe aucune restriction en ce qui concerne les liens circulaires suivants.
Considérons les liens et l’ordre des liens du diagramme « Liens d'association imbriqués » ci-dessus.
Si un lien est créé avec le chemin d’accès virtuel C:\Foo\Bar, un autre lien peut être créé avec C:\Foo comme chemin d’accès virtuel, et un autre avec C:\Foo\Bar\Baz comme chemin d’accès virtuel.
Par exemple :
- C:\Target existe sur le disque et contient un fichier Cat.txt
- C:\Target2 existe sur le disque et contient un fichier Dog.txt
- C:\Foo existe sur le disque avec un répertoire Bar
Si C:\Foo\Bar est lié à C:\Target (Lien1) et que C:\Foo est lié à C:\Target2 (Lien2), un utilisateur énumérant C:\Foo voit Dog.txt et le répertoire Bar, car celui-ci est un chemin virtuel pour son propre lien. Ensuite, si C:\Foo\Bar\Baz est lié à C:\Target2 (Lien3), un utilisateur énumérant C:\Foo\Bar voit Cat.txt et le répertoire Baz, dans la mesure où Baz est un chemin d’accès virtuel pour son propre lien.
Scénarios de lien d'association supplémentaires
Les points suivants sont importants et doivent toujours être pris en ligne de compte lorsqu'il s'agit de décider du résultat d'un lien ou d'un ensemble de liens :
Le chemin de stockage est toujours prioritaire et remplace toute entité portant le même nom qui existe dans le chemin d'accès virtuel ou en vertu d’un lien. Cela s’applique à tous les types de liens d'association.
Considérons par exemple le lien suivant :
C:\Foo est lié à C:\Target, où C:\Target est un fichier.
Dans ce cas, pour un lien sans ancrage, C:\Foo a l'apparence d'un fichier ayant des contenus de C:\Target. Même si C:\Foo est un répertoire qui existe localement (lien fantôme), le lien ci-dessus fait en sorte que C:\Foo ait l'apparence d'un fichier si le lien et le chemin de stockage existent.
En cas de conflit entre liens, celui dont la création est la plus récente est prioritaire. Cependant, le lien le plus récent ne peut pas masquer un lien antérieur.
Prenons un autre exemple, avec les liens suivants. Le deuxième lien modifie l'affichage de l’espace de noms.
- Lien1 : C:\Foo est lié à C:\Target, où C:\Target est un répertoire. C:\Target contient un fichier Bar
- Lien2 : C:\Foo\Bar est lié à C:\Target2, où Target2 est un répertoire contenant un fichier Cat.txt
Dans ce cas, une fois le Lien1 créé, C:\Foo contiendra un fichier Bar. Cependant, après la création du Lien2, C:\Foo affiche un répertoire Bar contenant un fichier Cat.txt. De même, si C:\Target2 était un fichier, C:\Foo\Bar serait un fichier avec les contenus de C:\Target2
En revanche, si l’ordre des liens était inversé comme indiqué ci-dessous, C:\Foo\Bar continuerait d’apparaître sous la forme d’un répertoire affichant Cat.txt à partir de C:\Target2. Le chemin de stockage est prioritaire sur les éléments situés dans un chemin d’accès virtuel, mais pas sur la propre racine du chemin d'accès virtuel.
- Lien1 : C:\Foo\Bar est lié à C:\Target2, où Target2 est un répertoire contenant un fichier Cat.txt
- Lien2 : C:\Foo est lié à C:\Target, où C:\Target est un répertoire. C:\Target contient un fichier Bar
Pour qu'un lien soit correctement créé, le parent du chemin d’accès virtuel doit soit exister localement, soit s’afficher en tant que backingPath d'un lien précédent, soit être lui-même un chemin d’accès virtuel dans un lien.
Par exemple, si C:\Foo est lié tout d'abord à C:\Target, puis C:\Foo\Bar\Baz est lié à un chemin de stockage, le lien en provenance de C:\Foo\Bar\Baz fonctionne si C:\Foo\Bar existe en vertu de l’une des conditions suivantes :
- C:\Foo\Bar existe localement et une exception dans le lien précédent garantit que C:\Foo\Bar n’a pas été masqué par C:\Target (veuillez vous reporter aux exceptions dans la Section suivante) ou
- C:\Foo\Bar existe en vertu du lien précédent (c'est-à-dire que C:\Target possède un répertoire Bar) ou
- C:\Foo\Bar est lui-même un chemin virtuel dans un autre lien (C:\Foo\Bar ==> quelque chose)
Remarque
Cela signifie que les liens imbriqués sans ancrage doivent être créés avec le lien le plus profond créé en dernier. Toutefois, les liens fantômes n’ont aucune restriction de ce type, car les chemins d'accès virtuels existent déjà sur le disque.
Considérons les liens suivants créés dans le même ordre :
- C:\Foo est lié à C:\Target
- C:\Foo\Bar est lié à C:\Target2
La création d’un lien n’a aucun effet sur le comportement du chemin de stockage. Par conséquent, le répertoire virtuel Bar s’affiche dans C:\Foo, et non dans C:\Target. La table de liaison se présente comme suit :
- C:\Foo --> C:\Target, C:\Foo\Bar --> C:\Target2 et non pas comme
- C:\Foo --> C:\Target, C:\Target\Bar --> C:\Target2
Exceptions aux liens d'association
En option, des exceptions peuvent être spécifiées pour limiter l’étendue du lien créé. Les chemins d’accès d’exception sont des descendants du chemin d’accès virtuel auxquels le lien ne s’applique pas. Les chemins d’accès d’exception peuvent être des fichiers ou des répertoires, mais ils doivent être des descendants du chemin d’accès virtuel. Les API nécessitent que les chemins d’accès d'exception soient accessibles au moment de la création du lien. L’exception s’applique à tous les descendants du chemin d’accès d’exception. Par exemple :
- C:\Foo existe sur le disque et contient un répertoire Bar et un répertoire Baz
- C:\Foo\Bar contient Cat.txt
- C:\Foo\Baz contient Dog.txt
- C:\Target existe sur le disque et contient un fichier Cow.txt
Si un lien est créé à partir de C:\Foo vers C:\Target avec une exception pour C:\Foo\Baz, l’utilisateur verra ce qui suit :
- C:\Foo contiendra le fichier Cow.txt de C:\Target et le répertoire Baz avec son fichier enfant Dog.txt. Notez que C:\Foo\Bar ne sera pas visible, car il a été masqué par le lien.
Le diagramme suivant illustre le scénario décrit ci-dessus :
Enfin, les exceptions aux liens d'association ne s’appliquent pas aux liens sans ancrage, puisque par définition, les chemins d'accès virtuels sans ancrage n’ont pas de descendants, et n’ont donc pas de chemins auxquels ces exceptions pourraient s'appliquer. En cas de tentative de transmission d’exceptions à un lien sans ancrage, l'API affiche une erreur.