Provided by: manpages-fr_3.07.1-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 numro dinud, 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 hierarchie 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
       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 :

       * 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  founis  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  premire  rgle  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 rgle 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  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.

       * 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’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.

       * 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érement. 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’otion -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.07  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> ».