Provided by: manpages-fr_3.23.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 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  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 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> ».