Lien symbolique

Sous un système Unix, les liens symboliques sont créés par la présence de l'option -s à la commande ln :

ln -s nom_du_fichier_pointé nom_du_lien_symbolique

Sous Windows et uniquement sur une partition NTFS[2], les liens symboliques sont créés par la présence de l'option /D dans une invite de commandes ; toutefois, il y a une inversion entre le lien et la cible (par rapport à la commande ln) :

MKLINK /D nom_du_lien_symbolique nom_du_fichier_pointé

Bien que l'ordre des arguments ressemble à celui des commandes cp et mv, il peut se révéler contre-intuitif : quand l'ordre des paramètres est inversé par erreur, le lien est créé à l'intérieur du répertoire pointé, et se référence lui-même ! Cela arrive quand on transpose mentalement la phrase « je veux aller de nom_du_lien_symbolique à nom_du_fichier_pointé » dans laquelle l'ordre des éléments est inverse. Une autre source de confusion est que pour liens relatifs, si nom_du_lien_symbolique ne se situe pas dans le répertoire courant, alors nom_du_fichier_pointé ne désigne pas le fichier tel qu'accessible depuis le répertoire courant : nom_du_fichier_pointé doit être résolu à partir du répertoire où se situera le lien.

Avec la version GNU de cp, il est possible de créer de façon beaucoup plus intuitive un lien symbolique vers un fichier donné. Ceci ne fonctionnera cependant pas avec les répertoires, et pour les liens relatifs, le lien symbolique à créer doit se trouver dans le répertoire courant. De plus, puisque cela n'est pas POSIX, il n'est pas recommandé d'utiliser cela dans un script (la version BSD de cp, entre autres, ne supporte pas cette option) :

cp -s nom_du_fichier_pointé nom_du_lien_symbolique

La plupart des opérations (lecture, écriture, exécution) sur un lien symbolique le déréférencent automatiquement et opèrent sur sa cible (le fichier réel). La suppression (rm) ou le déplacement/renommage (mv) portent sur le lien et n'affectent pas le fichier.

Un lien symbolique a toujours les mêmes droits d'accès que le fichier sur lequel il pointe. En réalité, les droits d'accès indiqués pour un lien symbolique sont sans signification. La commande chmod déréférence toujours les fichiers qui lui sont passés en argument et il n'est donc pas possible de donner des autorisations spécifiques au lien symbolique.

La commande d'affichage de contenu de répertoire ls représente les liens symboliques de la façon suivante :

lrwxrwxrwx  1 root root  9 2005-08-26 21:47 python -> python2.3

Le l de la première colonne indique que cette entrée est un lien symbolique. À l'extrême droite de la ligne sont affichés les caractéristiques de ce lien symbolique : quand l'utilisateur accèdera à python, il sera redirigé de façon transparente par le système vers la version python2.3. Dans cet exemple, le lien symbolique a été créé pour conserver à la fois plusieurs versions (2.1, 2.2, 2.3, etc.) du langage Python.

Contrairement aux liens physiques, les liens symboliques peuvent pointer sur des fichiers ordinaires, des répertoires, sur eux-mêmes ou sur des cibles qui n'existent pas (l'existence du nom_du_fichier_pointé n'est même pas vérifiée lors de la création du lien par la commande ln). C'est seulement au moment d'accéder à un lien symbolique que la vérification est faite. Quand la cible d'un lien symbolique n'existe pas, on dit que le « lien est cassé » (broken link, en anglais). Une tentative d'ouvrir en lecture un lien cassé conduit à un message d'erreur de type « fichier non trouvé », assez surprenant car le lien symbolique existe bel et bien.

Les liens symboliques peuvent être source de mauvaises surprises aux débutants, car ils donnent l'impression qu'un fichier est présent de multiples fois dans l'arborescence du système de fichiers. Une suppression de la cible faite dans l'illusion que ce même fichier existe ailleurs (alors que ce ne sont que des liens), conduit alors à la perte définitive du fichier, et casse instantanément tous les liens symboliques qui pointaient dessus.

Certains vieux programmes, créés alors que les liens n'existaient pas, peuvent avoir des conséquences assez catastrophiques quand ils sont confrontés à des liens, qu'ils soient symboliques ou physiques. Dans le meilleur des cas, ils peuvent tomber dans une boucle sans fin en tentant de suivre indéfiniment une arborescence liée sur elle-même. Au pire, la suppression d'un lien symbolique pointant sur un répertoire conduira à la suppression du contenu du répertoire lié. Fort heureusement, la gestion des liens par Unix est assez ancienne, et il est peu probable de rencontrer de tels programmes. Cependant, cela n'empêche pas le système de se protéger en interdisant, par exemple, la suppression d'un lien symbolique pointant sur un répertoire au moyen de la commande rmdir (comportement typique d'un programme non prévu pour les liens).

Nom A (de type slow symlink) et Nom C (de type fast symlink) sont deux liens symboliques pointant sur Nom B.

Les premières implémentations des liens symboliques traitaient les informations concernant le fichier pointé comme les données d'un fichier ordinaire. Ce fichier ordinaire contenait juste la chaîne de caractères représentant le nom du fichier pointé et seul un drapeau indiquait au système de ne pas ouvrir ce fichier, mais celui dont le nom y était indiqué.

Cette méthode a l'avantage d'être simple à réaliser mais présente cependant deux inconvénients. Premièrement, chaque ouverture d'un fichier via un lien symbolique ouvre en réalité deux fichiers, et même plus si le chemin d'accès au fichier est lui-même constitué de liens symboliques. Ces ouvertures multiples ralentissent le système. Deuxièmement, les quelques octets nécessaires au stockage du nom du fichier pointé étant considérés comme un fichier, ils occupent la place d'une unité d'allocation complète sur le disque, ce qui entraine un gaspillage de l'espace de stockage. Cette première implémentation a été rétroactivement appelée slow symlink.

Une évolution appelée fast symlink est à la fois plus rapide et moins dispendieuse en capacité de stockage. Elle consiste à stocker la chaîne de caractères représentant le nom du fichier pointé dans une zone supplémentaire de l'inode. Ceux-ci contenant les informations vitales du système de fichiers, ils sont souvent utilisés par le système, qui les maintient donc en mémoire centrale pour leur garantir un accès immédiat. Le nom du fichier pointé faisant partie de cette structure, il bénéficie lui aussi de cet accès rapide en mémoire, ce qui accélère grandement son déréférencement. Cependant, le système peut se replier sur l'ancienne méthode (lente) si la longueur de la chaîne de caractères dépasse les capacités limitées de stockage d'un inode.

• Sous Windows, les liens symboliques sont connus sous le nom de points de jonction (reparse point) depuis XP, disponibles uniquement avec le formatage NTFS. Ils peuvent pointer n'importe quel répertoire local (même sur un autre disque, qui doit être lui aussi formaté en NTFS). Ils sont créés avec la commande mklink, apparue avec Windows Vista[3]. Il est également possible d'utiliser l'outil fsutil avec l'option hardlink, intégré dès Windows XP. Il ne faut pas les confondre avec les fichiers raccourcis portant l'extension .lnk qui assurent une redirection seulement lorsqu'ils sont interprétés par l'application qui les ouvre.
• Sous Mac OS X, les liens symboliques ne doivent pas être confondus avec les alias. Contrairement aux raccourcis, les alias s'adaptent aux déplacements du fichier pointé, c'est-à-dire que si on déplace le fichier pointé, l'alias pointera toujours dessus alors que le lien symbolique (raccourci) ne sera pas en mesure de retrouver le fichier déplacé et sera donc inutile.
• Sous OS/2, les liens symboliques sont ou étaient connus sous le nom de shadows dans la version anglaise.