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

Linux                                             18 juin 2008                                        SYMLINK(7)