|
|
|
 History |
|
|
|
Page précédente : De l'utilité des liens... Liens symboliques et liens en durSommaire :
Sous Linux, il existe deux sortes de liens, les liens symboliques (aussi appelés symlinks) et les liens en dur (aussi appelés 'liens matériels', ou 'liens physiques' ou même, dans certains messages d'erreur de Mandriva 'liens directs'; en anglais hard links). Sans entrer dans des explications techniques ou théoriques, nous voudrions simplement signaler brièvement ici leurs principales propriétés, celles qui permettent de bien les différencier et de les utiliser. "Voir" la différence...La différence entre les deux types de lien apparaît de façon immédiatement visible dans l'affichage résultant de la commande 'ls', comme nous allons le voir tout de suite. On peut créer les deux sortes de liens à l'aide de la commande 'ln'. Avec l'option '-s' un lien symbolique sera créé, sans cette option on obtiendra un lien en dur. Supposons que le fichier charlotte3.txt existe dans notre répertoire de travail, la commande 'ls -li' (l'option '-i' entraîne l'affichage du 'numéro d'inode' de chaque fichier ou répertoire en début de ligne) donnant par exemple pour ce fichier : 1606777 -rw-r--r-- 1 toto toto 3407 fév 27 12:57 charlotte3.txt et créons un lien symbolique 'charlotte' vers ce fichier ainsi qu'un lien en dur best_charlotte : ln charlotte3.txt best_charlotte ln -s charlotte3.txt charlotte 1606777 -rw-r--r-- 2 toto toto 3407 fév 27 12:57 best_charlotte 1606777 -rw-r--r-- 2 toto toto 3407 fév 27 12:57 charlotte3.txt 1610496 lrwxrwxrwx 1 toto toto 14 fév 28 14:52 charlotte -> charlotte3.txt On voit d'abord que :
Pour mémoire, avant la création du lien en dur pour charlotte3.txt on avait ceci : 1606777 -rw-r--r-- 1 toto toto 3407 fév 27 12:57 charlotte3.txt et maintenant : 1606777 -rw-r--r-- 2 toto toto 3407 fév 27 12:57 charlotte3.txt Quelle est la différence ?? Le nombre qui précède immédiatement toto est passé de 1 à 2 :
Liens vers un répertoire
Un lien symbolique peut pointer vers un fichier ou vers un répertoire. Un lien en dur pointe uniquement vers un fichier, jamais vers un répertoire.
Rappel : Le nombre qui précède le nom du propriétaire dans une ligne obtenue par la commande 'ls' représente :
Le respect des frontières : liens et partitions
Un lien en dur ne peut pointer que vers un fichier qui se trouve sur la même partition que lui, une telle contrainte ne vaut pas pour les liens symboliques.
Et si j'efface l'original ?Si dans l'exemple qui précède j'efface le fichier original charlotte3.txt les conséquences sont radicalement différentes : le lien symbolique pointe désormais dans le vide, on ne peut plus accéder au contenu du fichier par son entremise. Il devient en fait inutilisable. En revanche, le lien en dur nous permet toujours d'accéder tout à fait normalement au contenu du fichier effacé charlotte3.txt et on peut même reconstituer ce dernier tout simplement par copie. Un fichier ne sera définitivement irrécupérable que lorsque le dernier de tous ses liens en dur présents sur sa partition aura été effacé. Et si je déplace l'original ?Ma foi déplacer, en un sens, c'est effacer et copier ailleurs… et en tout cas ce qui vient d'être dit de l'effacement vaut du déplacement. Si je déplace charlotte3.txt le lien symbolique charlotte devient inutilisable, en revanche le lien en dur best_charlotte n'est pas affecté. Et si le fichier original est dans un répertoire interdit ?Si un lien symbolique pointe vers un fichier qui se trouve dans un répertoire pour lequel vous n'avez pas de permissions d'accès appropriées, vous ne pourrez pas davantage accéder au fichier par le lien que par un accès direct à l'original. En revanche, vous pourrez accéder au fichier par un lien en dur, si vous avez les permissions pour lire le fichier lui-même : peu importe alors que le lien en dur accessible ait été créé par root à partir du répertoire d'un autre utilisateur qui vous est interdit. Le lien en dur peut donc être un bon moyen de circonvenir cette interdiction (cela peut donc être un bon moyen pour mettre à la disposition d'un autre utilisateur un fichier qui est dans votre répertoire personnel, et cela le sera d'autant plus que le fichier sera très volumineux, une image ISO par exemple, qui ainsi n'aura pas à être copiée). Copier un lienPour la copie d'un lien en dur voir CP-12 et ce paragraphe de CP-13. Pour la copie d'un lien symbolique voir CP-11 et ce paragraphe de CP-13 sur '-P', ainsi que celui-ci sur '-R'. Utilité de l'un et de l'autreLes liens symboliques sont apparemment plus couramment utilisés que les liens en dur. Les exemples de liens auxquels nous avons renvoyé à la page précédente sont en fait des exemples de liens symboliques. Un exemple d'emploi de lien en dur est suggéré plus haut. Etant donné qu'ils permettent de 'récupérer' le contenu d'un fichier effacé, il a parfois été proposé d'utiliser les liens en dur comme une sorte de 'sauvegarde' partielle. Ce qui précède devrait vous guider dans l'utilisation de l'un et de l'autre. Fournir un lien symbolique comme argument à une commandeLorsqu'une commande du shell accepte un fichier ou un répertoire comme argument, la question peut se poser à l'utilisateur de savoir ce qui se passerait si l'on mettait dans la ligne de commande, en position d'argument, non plus un fichier ou un répertoire, mais un lien symbolique pointant vers un fichier ou un répertoire. La commande prendra-t-elle alors en compte le lien lui-même ou ce vers quoi il pointe ?? Eh bien, cela dépend... Certaines commandes prennent en compte, 'par défaut', c'est-à-dire dans leur emploi 'normal', ce vers quoi pointe le lien, d'autres considèrent au contraire uniquement que l'argument est le lien lui-même. Prenons deux exemples très simples. Ces deux exemples impliquent des liens symboliques pointant vers des fichiers (et non des répertoires). La commande 'rm' qui permet d'effacer un fichier, appliquée à un argument qui a le statut de lien symbolique pointant vers un fichier, effacera le lien lui-même et n'affectera pas le fichier vers lequel pointait ce lien (ce qui paraît d'une prudence raisonnable...). La commande 'cat', au contraire, qui envoie vers la 'sortie standard' (stdout), c'est-à-dire le plus souvent vers l'écran, le contenu d'un fichier texte qu'on lui passe en argument, affichera le contenu du fichier texte vers lequel pointerait un lien qu'on lui passerait en argument (elle n'afficherait pas les quelques octets contenus dans le lien lui-même). 'rm' opère donc, du moins dans ce cas, sur le lien lui-même, (attention : si le lien pointe vers un répertoire, il en va différemment !), tandis que 'cat' opère sur le fichier vers lequel pointe le lien. La morale de tout ceci est que si vous utilisez une commande de telle sorte qu'elle porte sur un vaste ensemble d'arguments, soit parce que la commande est récursive (et peut donc affecter des répertoires et tout leur contenu, y compris leurs sous-répertoires et ce qu'ils contiennent eux-mêmes), soit parce que vous avez recours à l'expansion des noms de fichiers, alors il peut être prudent de vous renseigner, en regardant les pages de man ou d'info, sur le comportement qu'adoptera la commande si, parmi les divers arguments qui lui sont ainsi passés, figurent des liens symboliques. Si le comportement par défaut de la commande vis-àvis des liens symboliques vous convient, parfait. Mais, si ce n'est pas le cas, notez que, bien souvent, ce comportement par défaut pourra être modifié par certaines options passées à la commande (un exemple particulièrement riche : les options '-a', '-d', '-R', '-P' et '-L' de la commande 'cp'). Encore une fois, regardez alors de près la documentation de la commande qui vous intéresse. Cela dit, les choses peuvent être un peu plus compliquées. Par exemple, si un lien symbolique lien_lien pointe vers un répertoire, une commande cd lien_lien fera du répertoire vers lequel pointe lien_lien votre répertoire de travail. MAIS notez que, dans ce cas, l'invite du shell, si vous l'avez configurée pour qu'elle affiche le nom et le chemin du répertoire de travail, ou la commande pwd, vous donneront ensuite, par défaut, pour votre nouveau répertoire de travail, le nom et le chemin du lien (et une commande comme cd .. qui vous place dans le répertoire parent agira en conséquence), en revanche si vous utilisez l'option -P ainsi : cd -P lien_lien alors vous aurez une invite et un pwd qui correspondront exactement au répertoire où vous vous trouverez et qui ne tiendront pas compte du nom et du chemin du lien qui vous a permis d'y accéder. Si lien_lien pointe vers le répetoire /home/toto/condiments/, voici ce qui pourra se passer : [toto@localhost ~] cd lien_lien [toto@localhost ~/lien_lien] pwd /home/toto/lien_lien [toto@localhost ~] cd -P lien_lien [toto@localhost ~/condiments] pwd /home/toto/condiments Notez, pour terminer, que pour certaines commandes, si le nom d'un lien qui pointe vers un répertoire est passé 'tout sec', 'réduit à l'ui-même', c'est le lien qui sera considéré comme argument, alors que si le nom du lien passé en argument est suivi d'une barre oblique (''/'), ce sera alors le répertoire vers lequel pointe le lien qui sera en fait considéré comme argument. Par exemple, on le sait, on peut donner un répertoire comme argument à la commande 'ls', pour que celle-ci affiche la liste des fichiers et sous-répertoire à la racine de l'argument. Le résultat sera le même, que le nom du répertoire soit suivi d'une barre oblique ou non. Ainsi, si le répertoire 'condiments' est à la racine de votre répertoire de travail, les commandes : ls condiments ls condiments/ Mais, si 'cond' est un lien symbolique vers le répertoire 'condiments', alors : ls cond ls condiments/ Vous pourrez vérifier que la commande 'find' adopte un comportement analogue. Vous en trouverez une application dans le script aSauver.sh attaché à la page Une protection contre les effacements accidentels. Autres ressourcesUne protection contre les effacements accidentels, ou de l'utilité des liens en dur Auteur : ptyxs (février 2006) Legal: This page is covered by the GNU Free Documentation License . Standard disclaimers of warranty apply. Copyright LSTB and Mandrakesoft. |
|
Sachant tout ce que nous savons, si nous découvrons par un 'ls -li' qu'un certain fichier possède 4 'noms', comment trouver les 3 autres ??
Réponse : Puisque tous les 'noms' possèdent le même numéro d'inode, il suffit d'utiliser - sous root si vous cherchez sur tout le système - la commande 'find' avec l'option '-inum' :