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  reference  directe   vers   l'objet
       sous-jacent  pointe par le nom original. (Pour etre precis, chaque lien
       physique sur un fichier fait reference  au  meme  num'ero  d'inoeud,  ce
       numero  etant  un  indice  dans  une  table  d'inoeud  qui contient des
       meta-donnees sur tout le contenu  du  systeme  de  fichiers.  Consultez
       stat(2)).  Les  changements  dans  un  fichier sont independants du nom
       utilise pour faire reference au fichier. Les liens physiques ne peuvent
       pas  faire  reference aux repertoires (pour eviter le risque de boucles
       dans le systeme de fichiers, ce qui planterait de nombreux  programmes)
       et  ne  peuvent  pas  referencer  des  fichiers sur un autre systeme de
       fichiers (car les numeros d'inoeud ne sont  uniques  que  sur  un  meme
       systeme de fichiers).

       Un  lien  symbolique  est un fichier d'un type special, dont le contenu
       est une chaine representant le chemin d'acces 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
       reference aux  repertoires  et  peuvent  franchir  les  frontieres  des
       systemes de fichiers.

       Il n'y a pas d'obligation pour que le fichier dont le nom est reference
       par un lien symbolique existe. Un lien symbolique qui fait reference  a
       un nom de fichier inexistant est dit dangling link (pendouillant).

       Comme  un  lien symbolique et l'objet qu'il reference coexistent sur le
       systeme de fichiers, une confusion peut  survenir  pour  distinguer  le
       lien  lui-meme  et l'objet reference. Sur des systemes historiques, les
       commandes et les appels systeme  adoptaient  leur  propres  conventions
       pour  le  suivi des liens symboliques de maniere arbitraire. Des regles
       pour une approche plus uniforme,  comme  elles  sont  implementees  sur
       Linux  et  d'autres systemes, sont presentees ici. Il est important que
       les applications locales se conforment aussi  a  ces  regles  pour  que
       l'interface avec l'utilisateur soit la plus coherente possible.

   Propri'et'es, permissions, et horodatage des liens symboliques
       Le  proprietaire  et  le groupe d'un lien symbolique existant peut etre
       modifie en utilisant lchown(2). Le seul moment ou  l'appartenance  d'un
       lien  symbolique  est  importante  est lors de sa suppression ou de son
       renommage dans un repertoire dont le bit  << Sticky >>  est  positionne
       (consultez stat(2)).

       Les  horodatages  du  dernier acces et de la derniere modification d'un
       lien symbolique peuvent etre  modifies  en  utilisant  utimensat(2)  ou
       lutimes(3).

       Sur  Linux,  les  permissions  associees  au  lien  symbolique  ne sont
       utilisees dans aucune operation ; ces permissions  sont  toujours  0777
       (lecture,   ecriture   et   execution   pour   toutes   les  categories
       d'utilisateurs) et ne peuvent pas etre modifiees.

   Traitement des liens symboliques par les appels syst`eme et les commandes
       Les liens symboliques  sont  traites  en  agissant  soit  sur  le  lien
       lui-meme,  soit sur l'objet pointe par le lien. Dans ce dernier cas, on
       dit que l'application ou  l'appel  systeme  suit  le  lien.  Les  liens
       symboliques  peuvent  faire  reference  a  d'autres  liens symboliques,
       auquel cas les liens sont suivis jusqu'a ce qu'un objet qui ne soit pas
       un  lien  symbolique soit rencontre, qu'un lien symbolique pointant sur
       un fichier inexistant soit trouve, ou qu'une boucle soit detectee.  (La
       detection  des boucles est faite en definissant une limite maximale sur
       le nombre de liens qui peuvent etre suivis, et une erreur se produit si
       cette limite est atteinte).

       Il  faut  considerer  trois domaines d'utilisation differents des liens
       symboliques. Ce sont :

       1. Les liens symboliques fournis en argument des  appels  systeme  sous
          forme de noms de fichiers.

       2. Les  liens  symboliques  indiques  comme  arguments  de  la ligne de
          commande pour les utilitaires qui ne parcourent  pas  l'arborescence
          des fichiers.

       3. Les  liens symboliques rencontres par les utilitaires qui traversent
          l'arborescence  (soit  indiques  sur  la  ligne  de  commande,  soit
          rencontres comme partie de la hierarchie des fichiers).

   Appels syst`eme
       Le  premier domaine est celui des liens symboliques utilises en noms de
       fichiers comme argument pour les appels systeme.

       Sauf exception mentionnee ci-dessous, tous les appels  systeme  suivent
       les liens symboliques. Par exemple s'il existe un lien slink qui pointe
       vers le fichier afile, l'appel systeme open("slink"  ...)  renverra  un
       descripteur de fichier faisant reference a afile.

       Certains  appels  systeme  ne suivent pas les liens, et agissent sur le
       lien  symbolique   lui-meme.   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  systeme
       suivent   eventuellement   les   liens   symboliques.  Il  s'agit  de :
       faccessat(2), fchownat(2), fstatat(2), linkat(2), open(2), openat(2) et
       utimensat(2) ;  Reportez-vous  a  leur pages de manuel. Comme remove(3)
       est un alias pour unlink(2), cette fonction de bibliotheque ne suit pas
       non  plus les liens symboliques. Quand rmdir(2) est utilise sur un lien
       symbolique, il echoue avec l'erreur ENOTDIR.  L'appel  link(2)  reclame
       une  discussion  particuliere.  POSIX.1-2001  precise  que link(2) doit
       dereferencer oldpath si c'est un lien symbolique. Neanmoins,  Linux  ne
       le  fait  pas.  (Par  defaut,  Solaris  non  plus,  mais  une option de
       compilation permet d'obtenir le comportement POSIX.1-2001). La revision
       a  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, indiques en tant que
       noms  de  fichiers, comme argument pour des commandes ne traversant pas
       les arborescences.

       Sauf exception mentionnee 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  nomme  afile,  la
       commande cat slink affichera le contenu du fichier afile.

       Notez  bien que cette regle s'applique a des commandes qui peuvent dans
       d'autres situations parcourir l'arborescence, par exemple  la  commande
       chown  file  suit  cette  regle,  alors  que chown -R file, qui descend
       l'arborescence, ne la suit pas. (Cette derniere  est  traitee  dans  la
       troisieme partie ci-dessous).

       Si  on  desire  qu'une  commande agisse sur le lien symbolique lui-meme
       plutot 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 etre utilisee. Dans cet  exemple,  la  commande  chown
       root  slink  modifierait l'appartenance du fichier reference par slink,
       tandis que chown -h root  slink  modifierait  l'appartenance  de  slink
       lui-meme.

       Il y a quelques exceptions a cette regle :

       * 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  detruire.  (Notez  que  si  lorsqu'un  lien  symbolique fait
         reference a un fichier par un  chemin  relatif,  il  peut  cesser  de
         fonctionner  si  on  le deplace dans un autre repertoire ou le chemin
         relatif ne serait plus correct).

       * La commande ls(1) est aussi une exception a cette regle. Pour assurer
         la  compatibilite  avec  des  systemes  historiques,  quand  ls(1) ne
         descend pas une arborescence (c'est-a-dire si l'option -R  n'est  pas
         presente),  la  commande  ls(1) suit les liens symboliques fournis en
         argument si les options -H ou -L sont indiquees, ou  si  les  options
         -F,  -d  et -l ne sont pas presentes. (La commande ls(1) est la seule
         dont les options -H et -L modifient le comportement meme  lorsqu'elle
         ne fait pas un parcours d'arborescence).

       * La  commande  file(1)  est  aussi  une  exception a cette regle. 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 mentionnee.

   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  regles  ci-dessous  s'appliquent
       tant aux liens symboliques rencontres durant un parcours d'arborescence
       qu'aux liens fournis en argument de ligne de commande.

       La premi`ere r`egle s'applique aux liens  qui  referencent  des  fichiers
       autres  que  des  repertoires. Les operations entreprises sur ces liens
       sont appliquees sur les  liens  eux-memes,  ou  alors  les  liens  sont
       ignores.

       La  commande  rm -r slink directory effacera slink, ainsi que tout lien
       symbolique rencontre durant le parcours de  directory,  car  les  liens
       symboliques  peuvent  etre  effaces.  En aucun cas rm(1) ne touchera au
       fichier reference par slink.

       La seconde r`egle s'applique aux liens symboliques qui pointent vers des
       repertoires.  Sauf  mention contraire, ces liens ne sont jamais suivis.
       On parle souvent d'un  parcours  << physique >>  par  opposition  a  un
       parcours  << logique >>  (ou les liens symboliques vers des repertoires
       seraient suivis).

       Certaines conventions sont (ou devraient etre)  respectees  autant  que
       possible par les commandes parcourant des arborescences de fichiers :

       * Une commande peut etre forcee a suivre n'importe quel lien symbolique
         indique 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  representation  des  noms  sur  les
         lignes  de  commande conforme a l'espace logique des noms. (Notez que
         pour les commandes qui ne  parcourent  pas  toujours  l'arborescence,
         l'option   -H  sera  ignoree  si  l'option  -R  n'est  pas  egalement
         presente.)

         Par exemple, la commande chown -HR user slink parcourra la hierarchie
         debutant  par  le fichier pointe par slink. Remarquez que l'option -H
         n'est pas la meme que l'option -h traitee precedemment.  L'option  -H
         permet  de  suivre  les  liens  symboliques  indiques sur la ligne de
         commande aussi bien pour l'action a executer que pour le parcours  de
         l'arborescence ; tout se passe comme si l'utilisateur avait fourni le
         nom du fichier reference par le lien symbolique.

       * Une commande peut etre forcee a suivre les liens symboliques  sur  sa
         ligne  de  commande,  ainsi  que  tous les liens rencontres durant le
         parcours, quel que soit le type des fichiers qu'ils  referencent,  en
         utilisant  l'option -L (<< logical >>). Cette option permet de rendre
         l'espace reel des noms semblable a l'espace logique. (Notez  que  les
         commandes qui ne font pas systematiquement de parcours d'arborescence
         ignoreront l'option -L si l'option -R n'est pas presente).

         Par   exemple,   la   commande   chown -LR   user   slink   modifiera
         l'appartenance  du  fichier reference par slink. Si slink pointe vers
         un repertoire, chown(1)  descendra  l'arborescence  a  partir  de  ce
         repertoire.  En  outre,  si  des  liens  symboliques  sont rencontres
         pendant le parcours de chown(1), ils seront traites de la meme  facon
         que slink.

       * Une  commande  peut etre forcee a employer le comportement par defaut
         en utilisant l'option -P (pour << physique >>). Cet  attribut  permet
         de rendre l'espace des noms semblable a l'espace physique.

       Pour les commandes qui ne parcourent pas d'arborescence par defaut, les
       options -H, -L et -P sont ignorees si l'option -R n'est  pas  presente.
       De  plus,  vous  pouvez indiquer -H, -L et -P plusieurs fois ; c'est la
       derniere option qui determinera le comportement de  la  commande.  Ceci
       permet   de   creer  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)  presentent  des  exceptions  pour ces
       regles :

       * La commande rm(1) agit toujours sur le lien symbolique, et jamais sur
         le  fichier  qu'il  reference.  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  compatibilite  avec  systemes  historiques,  la
         commande  ls(1)  agit  quelque peu differemment. Si on ne precise pas
         d'option -F, -d ou -l, alors ls(1) suivra les liens indiques  sur  la
         ligne  de  commande. Si l'option -L est mentionnee, ls(1) suivra tous
         les liens symboliques, quels que soient leurs types, et qu'ils soient
         fournis   sur  la  ligne  de  commande  ou  rencontre  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      etre       trouvees       a       l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis  2010,  cette  traduction est maintenue a l'aide de l'outil po4a
       <URL:http://po4a.alioth.debian.org/>   par   l'equipe   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   ecrivant   a
       <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
       paquet manpages-fr.

       Vous pouvez toujours avoir acces a la version anglaise de  ce  document
       en utilisant la commande << man -L C <section> <page_de_man> >>.