NOM
symlink - Fonctionnement des liens symboliques
Les liens symboliques sont des fichiers qui agissent comme des
pointeurs vers d’autres fichiers. Pour comprendre leur fonctionnement,
vous devez d’abord comprendre comment fonctionnent les liens physiques.
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.
Propriétés permissions, et horodatage des liens symboliques
Le propriétaire et le groupe d’un lien symbolique existant peut être
modifié en utilisant lchown(2). Le seul moment où l’appartenance d’un
lien symbolique est importante est lors de sa suppression ou de son
renommage dans un répertoire dont le bit « Sticky » est positionné
(voir stat(2)).
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.
Traitement des liens symboliques par les appels système et les commandes
Les liens symboliques sont traités en agissant soit sur le lien
lui-même, soit sur l’objet pointé par le lien. Dans ce dernier cas, on
dit que l’application ou l’appel système suit le lien. Les liens
symboliques peuvent faire référence à d’autres liens symboliques,
auquel cas les liens sont suivis jusqu’à ce qu’un objet qui ne soit pas
un lien symbolique soit rencontré, qu’un lien symbolique pointant sur
un fichier inexistant soit trouvé, ou qu’une boucle soit détectée. (La
détection des boucles est faite en définissant une limite maximale sur
le nombre de liens qui peuvent être suivis, et une erreur se produit si
cette limite est atteinte).
Il faut considérer trois domaines d’utilisation différents des liens
symboliques. Ce sont :
1. Les liens symboliques fournis en argument des appels système sous
forme de noms de fichiers.
2. Les liens symboliques indiqués comme arguments de la ligne de
commande pour les utilitaires qui ne parcourent pas l’arborescence
des fichiers.
3. Les liens symboliques rencontrés par les utilitaires qui traversent
l’arborescence (soit indiqués sur la ligne de commande, soit
rencontrés comme partie de la hiérarchie des fichiers).
Appels système
Le premier domaine est celui des liens symboliques utilisés en noms de
fichiers comme argument pour les appels système.
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.
Les commandes qui ne parcourent pas les arborescences
Ce second domaine est celui des liens symboliques, indiqués en tant que
noms de fichiers, comme argument pour des commandes ne traversant pas
les arborescences.
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
troisiè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 modifierait l’appartenance du fichier référencé par slink,
tandis que chown -h root slink modifierait l’appartenance de slink
lui-même.
Il y a quelques exceptions à cette règle :
* Les commandes mv(1) et rm(1) ne suivent pas les liens symboliques
fournis en argument, mais essayent respectivement de les renommer ou
de les détruire. (Notez que si lorsqu’un lien symbolique fait
référence à un fichier par un chemin relatif, il peut cesser de
fonctionner si on le déplace dans un autre répertoire où le chemin
relatif ne serait plus correct).
* La commande ls(1) est aussi une exception à cette règle. Pour assurer
la compatibilité avec des systèmes historiques, quand ls(1) ne
descend pas une arborescence (c’est-à-dire si l’option -R n’est pas
présente), la commande ls(1) suit les liens symboliques fournis en
argument si les options -H ou -L sont indiquées, ou si les options
-F, -d et -l ne sont pas présentes. (La commande ls(1) est la seule
dont les options -H et -L modifient le comportement même lorsqu’elle
ne fait pas un parcours d’arborescence).
* La commande file(1) est aussi une exception à cette règle. Sauf
mention contraire, la commande file(1) ne suit pas les liens
symboliques fournis en argument. La commande file(1) ne suit les
liens symboliques que si l’option -L est mentionnée.
Les commandes parcourant une arborescence
Les commandes suivantes parcourent, toujours ou sur option,
l’arborescence des fichiers : chgrp(1), chmod(1), chown(1), cp(1),
du(1), find(1), ls(1), pax(1), rm(1) et tar(1).
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 :
* Une commande peut être forcée à suivre n’importe quel lien symbolique
indiqué sur la ligne de commande, quel que soit le type de fichier
vers lequel il pointe, en utilisant l’option -H (« half-logical »).
Cette option permet d’avoir une représentation des noms sur les
lignes de commande conforme à l’espace logique des noms. (Notez que
pour les commandes qui ne parcourent pas toujours l’arborescence,
l’option -H sera ignorée si l’option -R n’est pas également
présente.)
Par exemple, la commande chown -HR user slink parcourra 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.
* Une commande peut être forcée à suivre les liens symboliques sur sa
ligne de commande, ainsi que tous les liens rencontrés durant le
parcours, quel que soit le type des fichiers qu’ils référencent, en
utilisant l’option -L (« logical »). Cette option permet de rendre
l’espace réel des noms semblable à l’espace logique. (Notez que les
commandes qui ne font pas systématiquement de parcours d’arborescence
ignoreront l’option -L si l’option -R n’est pas présente).
Par exemple, la commande chown -LR user slink modifiera
l’appartenance 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.
* Une commande peut être forcée à employer le comportement par défaut
en utilisant l’option -P (pour « physique »). Cet attribut permet de
rendre l’espace des noms semblable à l’espace physique.
Pour les commandes qui ne parcourent pas d’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 :
* La commande rm(1) agit toujours sur le lien symbolique, et jamais sur
le fichier qu’il référence. Ainsi le lien n’est jamais suivi. La
commande rm(1) ne supporte pas les options -H, -L ou -P.
* Afin d’assurer une compatibilité avec systèmes historiques, la
commande ls(1) agit quelque peu différemment. Si on ne précise pas
d’option -F, -d ou -l, alors ls(1) suivra les liens indiqués sur la
ligne de commande. Si l’option -L est mentionnée, ls(1) suivra tous
les liens symboliques, quels que soient leurs types, et qu’ils soient
fournis sur la ligne de commande ou rencontré en parcourant
l’arborescence.
VOIR AUSSI
chgrp(1), chmod(1), find(1), ln(1), ls(1), mv(1), rm(1), lchown(2),
link(2), lstat(2), readlink(2), rename(2), symlink(2), unlink(2),
utimensat(2), lutimes(3), path_resolution(7)
COLOPHON
Cette page fait partie de la publication 3.23 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent être trouvées à l’adresse
http://www.kernel.org/doc/man-pages/.
TRADUCTION
Cette page de manuel a été traduite par Alain Portal <aportal AT
univ-montp2 DOT fr> en 2008, et mise à disposition sur
http://manpagesfr.free.fr/.
Veuillez signaler toute erreur de traduction en écrivant à
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce document
en utilisant la commande « man -L C <section> <page_de_man> ».