Provided by: manpages-fr_3.32d0.2p4-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  d'inud,  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.  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 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 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.32  du  projet  man-pages
       Linux.  Une description du projet et des instructions pour signaler des
       anomalies      peuvent      être       trouvées       à       l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis  2010,  cette  traduction est maintenue à l'aide de l'outil po4a
       <URL:http://po4a.alioth.debian.org/>   par   l'équipe   de   traduction
       francophone        au        sein        du       projet       perkamon
       <URL:http://perkamon.alioth.debian.org/>.

       Alain Portal <URL: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> ».