Provided by: manpages-fr_3.57d1p1-1_all bug

NOM

       symlink - Fonctionnement des liens symboliques

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é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. 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.

   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 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.57 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> ».