Un lien physique (hard link) vers un fichier est indistinguable du fichier original car c'est une référence directe vers l'objet sous-jacent pointé par le nom original. (Pour être précis, chaque lien physique sur un fichier fait référence au même numéro d'inœud, ce numéro étant un indice dans une table d'inœud qui contient des méta-données sur tout le contenu du système de fichiers. Voir stat(2)). Les changements dans un fichier sont indépendants du nom utilisé pour faire référence au fichier. Les liens physiques ne peuvent pas faire référence aux répertoires (pour éviter le risque de boucles dans le système de fichiers, ce qui planterait de nombreux programmes) et ne peuvent pas référencer des fichiers sur un autre système de fichiers (car les numéros d'inœud ne sont uniques que sur un même système de fichiers).
Un lien symbolique est un fichier d'un type spécial, dont le contenu est une chaîne représentant le chemin d'accès vers un autre fichier, celui vers lequel le lien pointe. En d'autres termes, un lien symbolique est un pointeur vers un autre nom, pas vers le contenu sous-jacent. Pour cette raison, les liens symboliques peuvent faire référence aux répertoires et peuvent franchir les frontières des systèmes de fichiers.
Il n'y a pas d'obligation pour que le fichier dont le nom est référencé par un lien symbolique existe. Un lien symbolique qui fait référence à un nom de fichier inexistant est dit dangling link (pendouillant).
Comme un lien symbolique et l'objet qu'il référence coexistent sur le système de fichiers, une confusion peut survenir pour distinguer le lien lui-même et l'objet référencé. Sur des systèmes historiques, les commandes et les appels système adoptaient leur propres conventions pour le suivi des liens symboliques de manière arbitraire. Des règles pour une approche plus uniforme, comme elles sont implémentées sur Linux et d'autres systèmes, sont présentées ici. Il est important que les applications locales se conforment aussi à ces règles pour que l'interface avec l'utilisateur soit la plus cohérente possible.
Les horodatages du dernier accès et de la dernière modification d'un lien symbolique peuvent être modifiés en utilisant utimensat(2) ou lutimes(3).
Sur Linux, les permissions associées au lien symbolique ne sont utilisées dans aucune opération ; ces permissions sont toujours 0777 (lecture, écriture et exécution pour toutes les catégories d'utilisateurs) et ne peuvent pas être modifiées.
Il faut considérer trois domaines d'utilisation différents des liens symboliques. Ce sont :
Sauf exception mentionnée ci-dessous, tous les appels système suivent les liens symboliques. Par exemple s'il existe un lien slink qui pointe vers le fichier afile, l'appel système open(slink ...) renverra un descripteur de fichier faisant référence à afile.
Certains appels système ne suivent pas les liens, et agissent sur le lien symbolique lui-même. Ce sont : lchown(2), lgetxattr(2), llistxattr(2), lremovexattr(2), lsetxattr(2), lstat(2), readlink(2), rename(2), rmdir(2), et unlink(2). Certains autres appels système suivent éventuellement les liens symboliques. Il s'agit de : faccessat(2), fchownat(2), fstatat(2), linkat(2), open(2), openat(2) et utimensat(2) ; Reportez-vous à leur pages de manuel. Comme remove(3) est un alias pour unlink(2), cette fonction de bibliothèque ne suit pas non plus les liens symboliques. Quand rmdir(2) est utilisé sur un lien symbolique, il échoue avec l'erreur ENOTDIR. L'appel link(2) réclame une discussion particulière. POSIX.1-2001 précise que link(2) doit déréférencer oldpath si c'est un lien symbolique. Néanmoins, Linux ne le fait pas. (Par défaut, Solaris non plus, mais une option de compilation permet d'obtenir le comportement POSIX.1-2001). La révision à venir de POSIX.1 changera de description pour permettre les deux comportements.
Sauf exception mentionnée ci-dessous, les commandes suivent les liens symboliques fournis en argument de ligne de commande. Par exemple, si un lien symbolique slink pointe vers un fichier nommé afile, la commande cat slink affichera le contenu du fichier afile.
Notez bien que cette règle s'applique à des commandes qui peuvent dans d'autres situations parcourir l'arborescence, par exemple la commande chown file suit cette règle, alors que chown -R file, qui descend l'arborescence, ne la suit pas. (Cette dernière est traitée dans la trosisième partie ci-dessous).
Si on désire qu'une commande agisse sur le lien symbolique lui-même plutôt qu'en le suivant, par exemple si on veut que chown slink change l'appartenance du fichier slink, que ce soit un lien symbolique ou non, l'option -h doit être utilisée. Dans cet exemple, la commande chown root slink modifirait l'appartenance du fichier référencé par slink, tandis que chown -h root slink modifirait l'appartenance de slink lui-même.
Il y a quelques exceptions à cette règle :
Il est important de remarquer que les règles ci-dessous s'appliquent tant aux liens symboliques rencontrés durant un parcours d'arborescence qu'aux liens fournis en argument de ligne de commande.
La première règle s'applique aux liens qui référencent des fichiers autres que des répertoires. Les opérations entreprises sur ces liens sont appliquées sur les liens eux-mêmes, ou alors les liens sont ignorés.
La commande rm -r slink directory effacera slink, ainsi que tout lien symbolique rencontré durant le parcours de directory, car les liens symboliques peuvent être effacés. En aucun cas rm(1) ne touchera au fichier référencé par slink.
La seconde règle s'applique aux liens symboliques qui pointent vers des répertoires. Sauf mention contraire, ces liens ne sont jamais suivis. On parle souvent d'un parcours « physique » par opposition à un parcours « logique » (où les liens symboliques vers des répertoires seraient suivis).
Certaines conventions sont (ou devraient être) respectées autant que possible par les commandes parcourant des arborescences de fichiers :
Par exemple, la commande chown -HR user slink parcourera la hiérarchie débutant par le fichier pointé par slink. Remarquez que l'option -H n'est pas la même que l'option -h traitée précédemment. L'option -H permet de suivre les liens symboliques indiqués sur la ligne de commande aussi bien pour l'action à exécuter que pour le parcours de l'arborescence ; tout se passe comme si l'utilisateur avait fourni le nom du fichier référencé par le lien symbolique.
Par exemple, la commande chown -LR user slink modifiera l'appartenace du fichier référencé par slink. Si slink pointe vers un répertoire, chown(1) descendra l'arborescence à partir de ce répertoire. En outre, si des liens symboliques sont rencontrés pendant le parcours de chown(1), ils seront traités de la même façon que slink.
Pour les commandes qui ne parcourent pas l'arborescence par défaut, les options -H, -L et -P sont ignorées si l'option -R n'est pas présente. De plus, vous pouvez indiquer -H, -L, et -P plusieurs fois ; c'est la dernière option qui déterminera le comportement de la commande. Ceci permet de créer des alias sur des commandes afin d'avoir un comportement choisi, et de surcharger ce comportement en ligne de commande.
Les commandes ls(1) et rm(1) présentent des exceptions pour ces règles :
Ce document est une traduction réalisée par Christophe Blaess <http://www.blaess.fr/christophe/> le 2 juillet 2008 et révisée le 17 juillet 2008.
L'équipe de traduction a fait le maximum pour réaliser une adaptation française de qualité. La version anglaise la plus à jour de ce document est toujours consultable via la commande : « LANG=C man 7 symlink ». N'hésitez pas à signaler à l'auteur ou au traducteur, selon le cas, toute erreur dans cette page de manuel.
Dernière mise à jour : 17 juillet 2008