[Plan du site]
Vous êtes ici ---
> Le Site du Zéro
> Les tutoriels
> Non-Officiels
> Systèmes d'exploitation
> Linux
> Apprenez le Shell > Initiation aux lignes de commande > Créer des liens
> Lecture du tutoriel
Créer des liens
Vous vous apprêtez à lire un tutoriel rédigé par un membre de ce site. Malgré tout le soin que ce membre a pu apporter au tutoriel, nous ne pouvons pas garantir que les informations contenues sur cette page sont exactes à 100%. Merci de garder cela en tête lorsque vous lirez cette page ;o)
Ben voilà le dernier chapitre de la première partie... Nous allons voir un nouveau type de fichiers, qui est un peu l'équivalent des raccourcis Windows.
La problématique est la suivante : vous avez des fichiers que vous aimez, et vous aimeriez pouvoir les lire à différents endroits.
Si vous avez suivi mon cours, vous allez me dire qu'à coups de
cp, on peut réaliser cela... Mais si c'est une vidéo qui fait pas mal de Méga-octets, je sens que votre disque dur va faire la tronche...
Avant de lire la suite, sachez juste que les liens sont très utiles dans le monde de Linux. Vous en utilisez sans le savoir depuis que vous avez installé Linux.
Inodes
Avant de vous parler des liens, il est indispensable de connaître un mot barbare : les
inodes (ou inoeuds en français, mais j'utiliserai inodes).
Vous devez savoir que dans l'ordinateur, tout est en 0 et en 1...
Quand vous créez un fichier, vous lui indiquez son nom (ou son
nom symbolique)... Mais l'ordinateur, lui, crée un nouveau numéro : l'inode. Il contient toutes les métadonnées que l'on a vues précédemment (les droits d'accès, les différentes dates, ...).
L'inode ne contient pas le nom du fichier.
Pour connaître cet élément, il suffit de taper :
Code : Console
Vous allez voir que c'est donné en décimal. C'est un convertisseur
nom symbolique /
inode : lorsque vous effectuez une commande, Linux va directement chercher le numéro de l'inode : s'il trouve ce numéro, il effectue ce que vous lui avez demandé.
Numéro fixé dès la naissance
Une fois que le fichier est créé, on peut lui faire tout ce que l'on veut, tant qu'il reste dans son système de fichier : il garde son numéro d'inode. Vous pouvez tester :
Code : Console | $ mkdir shell
$ cd shell
$ touch jarvis
$ ls -i |
Faites des déplacements, des changements de nom et d'état, ... L'inode est fixe.
Déplacez ce fichier sur une clé USB : l'inode a changé.
Chaque inode est conservé dans la table des inodes. Il y a une table d'inodes par système de fichier.
Libérer un inode
À chaque inode donné, il y a un fichier.
Lorsque le fichier est supprimé, l'inode est libéré ; quand vous allez créer un nouveau fichier, il pourra reprendre cet inode.
Code : Console | $ ls -i jarvis
$ rm jarvis |
On libère l'inode de jarvis.
Code : Console | $ mkdir coucou
$ ls -di coucou |
Vous allez voir que l'inode de jarvis libéré est la même que celle de coucou. L'inode de coucou a bien pris la place de l'inode de jarvis.

Vous pouvez remarquer que c'est totalement indépendant, que cela soit un répertoire ou un fichier ordinaire.
Résumons
J'ai fait un schéma pour récapituler les informations importantes pour la suite :
C'est un peu simplifié
Et si on réussissait à créer un fichier qui avait la même inode qu'un autre fichier, ça ne résoudrait pas notre problème ?
Ah : vous êtes très perspicace, jeunes padawans... Nous allons donc voir la fonction qui permet de faire cela .:)
Nous allons casser tout de suite le suspense...
Pour faire cela, nous allons utiliser la fonction
ln (abréviation de
link).
Fichier ordinaire
Tout d'abord, nous allons créer un fichier, soyons originaux :
Code : Console
Maintenant, créons le lien dit, physique ou
dur (en anglais :
hard link) "Jarvis Cocker" :
Code : Console | $ ln Jarvis Jarvis\ Cocker |
ln s'utilise de la façon suivante :
Code : Console | $ ln fichierExistant lienACréer |
Bien évidemment, j'ai simplifié : il est possible de créer un lien dur dans une autre branche de l'arborescence (si on en a les droits, cela va de soi, et si le système de fichiers est le même) : le lien dur ne dépend pas de l'arborescence...
Vérifions à présent que les deux fichiers ont le même inode :
Code : Console | $ ls -i Jarvis Jarvis\ Cocker
8968 Jarvis 8968 Jarvis Cocker |
Sur un schéma :
Et voilà : le tour est joué.

(Je vous conseille de tester, car je pourrais vous roulez dans la farine...

)
Bon : j'ai fait "du Jarvis\ Cocker" ; ça met 0 octet, mais bon, Jarvis aussi en fait 0...
Oui, je l'admets : cela ne prouve pas que ça n'occupe pas plus de place.
Prenez un gros fichier vidéo (enfin un fichier de plus de 100 Mo)...
Si vous tenez à ce fichier et que vous ne me faites pas confiance, vous pouvez faire un
cp...
Continuons :
Code : Console | $ ln grosFichVideo.mpg nouveauFichier.mpg |
Faites ensuite :
Code : Console | $ du -h grosFichVideo.mpg |
Code : Console | $ du -h nouveauFichier.mpg |
Et là vous voyez, avec stupeur et tremblement, que vous avez créé un autre gros fichier.
Alors c'est quoi, la différence avec cp ?
Je vous fais tout un discours sur les inodes, et après j'arrive à vous faire croire que ça ne sert à rien.
Faites :
Code : Console
Puis vous supprimez nouveauFichier.mpg :
Code : Console
et faites à nouveau :
Code : Console
Vous voyez bien que vous n'aviez rien créé de plus... En fait, le schéma montre bien ce que fait Linux. Quand vous lui indiquez le nom du fichier, il prend l'inode en compte, il voit que cet inode correspond à toutes les métadonnées, dont la taille du fichier, et il affiche donc cela, comme vous l'aviez demandé avec "
du -h". Utilisez la fonction
stat sur ces deux fichiers : vous verrez qu'ils ont
exactement les mêmes métadonnées.
Vous auriez pu supprimer "grosFichVideo.mpg" : ça n'aurait rien changé, mais je pense que psychologiquement, on a envie de supprimer le fichier que l'on vient de créer.
Autres choses intéressantes. Quand vous faites :
Code : Console | $ ls -l Jarvis "Jarvis Cocker" |
Vous pouvez remarquer qu'ils ont, tous les deux,
deux liens. C'est bizarre, non ?
En effet, je vous avais dit que tous les fichiers ordinaires avaient toujours un lien.
Mais en fait, ce ne sont plus vraiment des fichiers ordinaires : il y a maintenant un lien entre ces deux fichiers.
J'étais dans mon répertoire "shell" quand j'ai créé le lien physique.
Répertoire
Nous n'avons pris des exemples que pour des fichiers ordinaires. Mais qu'en est-il des répertoires qui contiennent des fichiers ?
Cela va vous rappeler des souvenirs

:
Code : Console | $ mkdir shell shell/essai1 shell/essai2 shell/essai1/essai1a
$ touch shell/fichier0 shell/essai1/fichier1 shell/essai2/fichier2 shell/essai1/essai1a/fichier1a |
Code : Console | $ ln shell/ bash
ln: `shell/': hard link not allowed for directory |
Arg... Ça ne marche pas.

(Je joue bien la déception, non ?)
Bon, Jarvis... C'est quand même un problème qu'on ne puisse pas faire de lien sur un répertoire...
Oui, c'est entre autres pour cela qu'on a inventé le lien symbolique.
Nous allons maintenant apprendre à créer des liens symboliques (en anglais :
symbolic link ou
symlink, ou encore
soft link). Contrairement au lien physique, le lien symbolique ne prend pas en compte l'inode, mais le nom symbolique du fichier.
On utilise la même fonction pour créer un lien
symbolique, mais il suffit d'ajouter l'option
-s (c'est pas trop dur à retenir ?

).
Fichier ordinaire
Créez un fichier "fichierExistant", puis tapez :
Code : Console | $ ln -s fichierExistant lienSymbolique |
Puis tapez :
Code : Console | $ ls -il fichierExistant lienSymbolique |
Et observez (aujourd'hui, j'ai envie de vous commander) :
Code : Console | 1135698 -rw-r--r-- 1 jarvis winner 0 Dec 20 20:35 fichierExistant
1135699 lrwxrwxrwx 1 jarvis winner 15 Dec 20 20:35 lienSymbolique -> fichierExistant |
Vous pouvez déjà remarquer plusieurs choses :
- L'inode du lien symbolique est différente de son fichier.
- Il est indiqué avec l que c'est un lien symbolique.
- Le lien symbolique occupe de la mémoire, mais très peu (si cela vous amuse, vous pouvez tester sur un fichier vidéo comme pour les liens physiques).
- La flèche explique bien ce que fait lienSymbolique.
Tenez : je vais vous apprendre une nouvelle option avec
ls :
-L
Code : Console | $ ls -ilL fichierExistant lienSymbolique |
Code : Console | 1135698 -rw-r--r-- 1 jarvis winner 0 Dec 20 20:35 fichierExistant
1135698 -rw-r--r-- 1 jarvis winner 0 Dec 20 20:35 lienSymbolique |
Vous pouvez observer que ces deux lignes sont quasi-identiques, seul le nom change (un peu comme si c'était un lien physique à l'exception du nombre de liens).
L'option
-L permet de
déréférencer le lien : en utilisant cette option, Linux remplace le lien symbolique par sa destination, tout en gardant son nom.
Mais, concrètement, c'est quoi la différence entre un lien dur et un lien symbolique ?
Eh bien supprimez le fichier "fichierExistant", et faites à nouveau :
Code : Console
Vous allez voir que le fichier "lienSymbolique" a une autre couleur (chez moi, c'est en rouge sur fond noir) : cela veut dire que ce lien ne fonctionne plus, il n'est plus utile : on dit qu'il est
cassé (
broken link, en anglais). Nous avons appris une nouvelle option, utilisez-la :
Code : Console | $ ls -L lienSymbolique
ls: lienSymbolique: No such file or directory |
Linux regarde quel nom symbolique va chercher le lien symbolique. Malheureusement, il voit que le nom symbolique n'existe pas : voilà pourquoi cette erreur survient.
Le lien n'est pas "mort", car si vous créez à nouveau le fichier "fichierExistant" au même endroit, il re-fonctionnera .

Faites cela.
Supprimez maintenant "lienSymbolique", puis observez
fichierExistant : il existe toujours.
Ainsi, vous pouvez le remarquer, le lien symbolique est beaucoup plus fragile que le lien dur : si vous bougez la destination, le supprimez, changez son nom, etc. le lien symbolique ne trouvera plus où est sa cible :
il ne fonctionnera plus.
Répertoire
Le principal avantage du lien symbolique sur le lien physique : on peut créer un lien symbolique sur un répertoire.

Vous avez encore l'exemple précédent qui a échoué ? Il suffit de rajouter un petit
-s pour que ça marche :
Code : Console
Code : Console est alors équivalent à
Code : Console
Vous pouvez bien entendu créer des liens symboliques sur n'importe quelle branche de l'arbre, en utilisant le chemin relatif ou absolu.
Autre avantage du lien symbolique : comme l'inode n'est pas la même, cela veut dire qu'il peut fonctionner sur différents systèmes de fichiers.
Vous avez une partition Windows ?
Si vous ne vous rappelez plus où elle se trouve,
allez au chapitre 5.
Pour ma partition, il faut taper :
Code : Console | $ ln -s /mnt/windows/ Windows |
Et voilà : le débutant en Linux (par exemple votre petit frère) n'aura pas besoin de savoir où est sa partition Windows.
Vous pouvez faire de même pour les clés USB, etc.
Un truc sympathique :
Code : Console
Remarquez la différence si vous aviez fait :
Code : Console
Mais si j'ai envie de supprimer un lien symbolique de répertoire, je fais comment ?
Pour le cas précédent :
Code : Console
Ne vous inquiétez pas, cela ne va pas vous supprimer Windows.
Je crois que nous avons fait le tour de la fonction
ln : pour être plus complets, vous pouvez lire le manuel de
ln.
Il ne reste plus qu'à bien savoir l'utiliser.
Les liens durs sont moins utilisés que les liens symboliques, du fait que les liens symboliques sont plus souples (on peut créer des "lien-répertoires", et les liens ne dépendent pas de la partition), moins déroutant pour un débutant : lorsqu'on fait
ls -l d'un lien dur, on peut facilement croire qu'il vaut vraiment telle quantité d'octets et que si on supprime ce lien dur, cela va libérer de la place, alors que pas du tout...

Sachez, enfin, que les liens symboliques ont un réel intérêt pour l'organisation de Linux... et cela vous simplifie grandement la vie.
Mais alors, quel est l'intérêt du lien physique ? Cela peut permettre, par exemple avec un script shell adapté, de créer une seconde chance à un fichier qui a été supprimé par erreur, une sorte de corbeille.
Les scripts shell ? Ah ! C'est l'objet de la prochaine partie (remarquez cette transition de fou

).