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.
A hard link to a file is indistinguishable from the original file because it is a reference to the object underlying the original filename. (To be precise: each of the hard links to a file is a reference to the same inode number, where an inode number is an index into the inode table, which contains metadata about all files on a filesystem. See stat(2).) Changes to a file are independent of the name used to reference the file. Hard links may not refer to directories (to prevent the possibility of loops within the filesystem tree, which would confuse many programs) and may not refer to files on different filesystems (because inode numbers are not unique across filesystems).
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).
On Linux, the permissions of a symbolic link are not used in any operations; the permissions are always 0777 (read, write, and execute for all user categories), and can’t be changed. (Note that there are some "magic" symbolic links in the /proc directory tree—for example, the /proc/[pid]/fd/* files—that have different permissions.)
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). |
Before describing the treatment of symbolic links by system calls and commands, we require some terminology. Given a pathname of the form a/b/c, the part preceding the final slash (i.e., a/b) is called the dirname component, and the part following the final slash (i.e., c) is called the basename component.
Treatment of
symbolic links in system calls
Le premier domaine est celui des liens symboliques
utilisés en noms de fichiers comme argument pour les
appels système.
The treatment of symbolic links within a pathname passed to a system call is as follows:
|
1. |
Within the dirname component of a pathname, symbolic links are always followed in nearly every system call. (This is also true for commands.) The one exception is openat2(2), which provides flags that can be used to explicitly prevent following of symbolic links in the dirname component. | ||
|
2. |
Except as noted below, all system calls follow symbolic links in the basename component of a pathname. For example, if there were a symbolic link slink which pointed to a file named afile, the system call open("slink" ...) would return a file descriptor referring to the file afile. |
Various system calls do not follow links in the basename component of a pathname, and operate on the symbolic link itself. They are: lchown(2), lgetxattr(2), llistxattr(2), lremovexattr(2), lsetxattr(2), lstat(2), readlink(2), rename(2), rmdir(2), and unlink(2).
Certain other system calls optionally follow symbolic links in the basename component of a pathname. They are: faccessat(2), fchownat(2), fstatat(2), linkat(2), name_to_handle_at(2), open(2), openat(2), open_by_handle_at(2), and utimensat(2); see their manual pages for details. Because remove(3) is an alias for unlink(2), that library function also does not follow symbolic links. When rmdir(2) is applied to a symbolic link, it fails with the error ENOTDIR.
link(2) warrants special discussion. POSIX.1-2001 specifies that link(2) should dereference oldpath if it is a symbolic link. However, Linux does not do this. (By default, Solaris is the same, but the POSIX.1-2001 specified behavior can be obtained with suitable compiler options.) POSIX.1-2008 changed the specification to allow either behavior in an implementation.
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).
If it is explicitly intended that the command operate on the symbolic link instead of following the symbolic link—for example, it is desired that chown slink change the ownership of the file that slink is, whether it is a symbolic link or not—then the -h option should be used. In the above example, chown root slink would change the ownership of the file referred to by slink, while chown -h root slink would change the ownership of slink itself.
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.
The second rule applies to symbolic links that refer to directories. Symbolic links that refer to directories are never followed by default. This is often referred to as a "physical" walk, as opposed to a "logical" walk (where symbolic links that refer to directories are followed).
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), namei(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 5.07 du projet man-pages Linux. Une description du projet et des instructions pour signaler des anomalies et la dernière version de cette page, peuvent être trouvées à l’adresse https://www.kernel.org/doc/man-pages/.
TRADUCTION
La traduction française de cette page de manuel a été créée par Christophe Blaess <https://www.blaess.fr/christophe/>;, Stéphan Rafin <stephan.rafin [AT] laposte.net>, Thierry Vignaud <tvignaud [AT] mandriva.com>, François Micaux, Alain Portal <aportal [AT] univ-montp2.fr>, Jean-Philippe Guérard <fevrier [AT] tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.coulon [AT] wanadoo.fr>, Julien Cristau <jcristau [AT] debian.org>, Thomas Huriaux <thomas.huriaux [AT] gmail.com>, Nicolas François <nicolas.francois [AT] centraliens.net>, Florentin Duneau <fduneau [AT] gmail.com>, Simon Paillard <simon.paillard [AT] resel.fr>, Denis Barbier <barbier [AT] debian.org>, David Prévot <david [AT] tilapin.org> et Frédéric Hantrais <fhantrais [AT] gmail.com>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n’y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à <debian-l10n-french [AT] lists.org>.