Lien Symbolique

Pour les articles homonymes, voir Lien.

Le « Nom B » est un lien symbolique sur le fichier « Nom A ».

Un lien symbolique (ou symlink) est une entrée spéciale de répertoire dans les systèmes Unix modernes (ou similaire à Unix) qui permet de référencer de manière quasi-transparente d'autres entrées de répertoire, typiquement, des fichiers ou des répertoires. On peut dire qu'un lien symbolique est un alias d'un fichier ou d'un répertoire.

On appelle déréférencement l'action du système d'exploitation consistant à remplacer le nom du symlink par celui qu'il pointe.

La commande permettant de retrouver le fichier pointé par le lien est readlink.

Utilisation

Les liens symboliques sont créés par la présence de l'option -s dans la commande ln :

ln -s nom_pointé nom_du_symlink

Bien que la syntaxe (l'ordre des arguments) soit similaires à celles des commandes cp et mv, elle est finalement contre-intuitive, et il arrive souvent que l'ordre des paramètres soit inversé par erreur, ce qui aboutit à des résultats surprenants : le lien est créé à l'intérieur du répertoire pointé, et se référence lui-même. L'origine de cette erreur provient probablement que l'on transpose mentalement la phrase « je veux aller de nom_du_symlink à nom_pointé » dans laquelle l'ordre des objets est exactement l'inverse de ce qu'ils seront dans la commande.

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. De plus, puisque cela n'est pas POSIX, il n'est pas recommandé d'utiliser ceci dans un script (la version BSD de cp, entre autres, ne supporte pas cette option).

cp -s fichier_pointé nom_du_symlink

La plupart des opérations (ouverture, lecture, écriture) sur un symlink le déréférence automatiquement et opèrent sur sa destination (le fichier ou répertoire réel). La suppression (rm) ou le déplacement/renommage (mv) portent sur le lien et n'affectent pas le fichier.

Un symlink 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é en argument et il n'est donc pas possible de donner des autorisations spécifiques au symlink.

La commande d'affichage de contenu de répertoire ls représente les liens symbolique 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 symlink : quand l'utilisateur accèdera à python, il sera redirigé de façon transparente par le système à python2.3. Dans cet exemple, le lien symbolique a été créé pour conserver à la fois plusieurs versions (2.1, 2.2, 2.3…) du langage python.

Contrairement aux liens matériels, les liens symboliques peuvent pointer sur des fichiers, des répertoires, sur eux-mêmes ou sur des destinations qui n'existent pas (l'existence du nom_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 symlink que la vérification est faite. Quand la destination d'un lien symbolique n'existe pas, on dit que le « lien est cassé » (broken link en anglais). Une tentative d'ouvrir un lien cassé conduit à un message d'erreur de type « fichier non trouvé », assez surprenant car le symlink 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 destination, 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 symlinks 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 matériels. 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 symlink 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 symlink pointant sur un répertoire au moyen de la commande rmdir (comportement typique d'un programme non prévu pour les liens).

Stockage des symlinks

« 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 la destination comme les données d'un fichier ordinaire. Ce fichier contenait juste la chaîne de caractère représentant le nom 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 symlink ouvre en réalité deux fichiers, et même plus si le chemin d'accès au fichier est lui-même constitué de symlinks. Ces ouvertures multiples ralentissent le système. Deuxièmement, les quelques octets nécessaires au stockage du nom 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é 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ère représentant le nom pointé dans une zone supplémentaire de l'inode. Ceux-ci contenant les informations vitales du système de fichier, 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 pointé faisant partie de cette structure, il bénéfice 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ère dépasse les capacités limitées de stockage d'un inode.

Autres systèmes d'exploitation

• Sous Windows de Microsoft, les liens symboliques sont connus sous le nom de « raccourcis ». Cependant, à la différence des systèmes Unix, ils sont implémentés sous forme de fichiers classiques portant l'extension « .lnk ». De plus, le déréférencement n'est pas effectué par le système, mais par l'interface graphique, ce qui oblige les programmes à utiliser une interface de programmation spécifique pour s'en servir. À partir de la version Windows 2000 de NTFS, il existe des « points de jonction » qui permettent de simuler le comportement des liens symboliques vers des répertoires locaux. [1] [2]
• Sous Mac OS X, les liens symboliques ne doivent pas être confondus avec les «  alias  ». Contrairement aux "raccourcis", les «  alias  » conservent les propriétés du fichier ciblé, c'est-à-dire que si c'est une application, on pourra y glisser dessus les documents compatibles pour les ouvrir avec, si c'est un document, il aura le code de 4 lettres dans ses ressources correspondant au type de fichier, et, vous pourrez donc glisser cet alias sur une application pour ouvrir le document réel, exactement comme si ce n'était pas un alias. Malgré ces apparentes similitudes au niveau de l'interface graphique, les alias ne sont pas des liens symboliques [3].
• Sous OS/2, les liens symboliques sont ou étaient connus sous le nom de « shadow » dans la version en anglais.

Voir aussi

• Liens matériels
• ln (Unix)
• rm (Unix) et unlink (Unix)
• readlink
• Liens symboliques et liens en dur