NOM¶
symlink - Fonctionnement des liens symboliques
DESCRIPTION¶
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étadonnées sur tout le contenu du système
de fichiers. Consultez
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. (Le contenu d'un lien symbolique
peut être lu en utilisant
readlink(2).) 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é (consultez
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.
Obtient un descripteur de fichier qui fait référence à un lien symbolique.¶
L'utilisation des attributs
O_PATH and
O_NOFOLLOW en association
pour un appel
open(2) délivre un descripteur de fichier qui peut
être transmis comme l'argument
dirfd à des appels
systèmes tels que
fstatat(2),
fchownat(2),
fchmodat(2),
linkat(2), et
readlinkat(2), afin d'agir sur
des liens symboliques (et non sur les fichiers vers lesquels ils pointent).
Par défaut (c'est à dire si l'attribut
AT_SYMLINK_FOLLOW
n'est pas précisé), lorsque
name_to_handle_at(2) est
utilisé sur un lien symbolique, il délivre un indicateur pour le
lien symbolique (et non pour le fichier vers lequel il pointe). On peut alors
obtenir un descripteur de fichier du lien symbolique (et non du fichier vers
lequel il pointe) en précisant l'attribut
O_PATH lors d'un appel
ultérieur à
open_by_handle_at(2). De nouveau, ce
descripteur de fichier peut être utilisé dans des appels
système cités précédemment pour agir sur le lien
symbolique en lui-même.
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),
name_to_handle_at(2),
open(2),
openat(2),
open_by_handle_at(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 prend pas en charge 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.65 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¶
Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a
<
http://po4a.alioth.debian.org/> par l'équipe de traduction
francophone au sein du projet perkamon
<
http://perkamon.alioth.debian.org/>.
Alain Portal <
http://manpagesfr.free.fr/> (2008).
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> ».