en pratique

Retour a la page principale

Dans cette rubrique, désormais régulière, nous parlerons chaque mois d'un aspect pratique de l'utilisation de Linux et de son environnement. Unix traine avec lui une rputation de complexite qui n'est que partiellement fondee et qui decourage parfois les utilisateurs a adopter Unix. Afin d'initier les (ex)inconditionnels du DOS a l'extraordinaire puissance de ce systeme, nous essaieron de montrer que si Unix est effectivement loin d'etre facile a apprehender, son apprentissage n'est tout de meme pas la mer a boire et, surtout, que le jeu en vaut la chandelle.

Entrons donc dans le vif du sujet et commencons par un point crucial:

Les liens de fichiers

Sommaire:

  1. A quoi ca sert?
  2. Les liens physiques
    1. Le secret des inodes
    2. Des fichiers a plusieurs noms
    3. Le revers de la medaille
  3. Liens symboliques
  4. Conclusion


1. A quoi ca sert?

Imaginez que vous venez de telecharger vingt megas de niveaux de Quake et, tremblant d'impatience, vous vous empressez de les gunzipper, tarxvfiser et... et c'est la que vous vous appercevez avec horreur que vous n'avez plus assez de place sous /usr/games. La seule solution est alors de les stocker sur votre disque SCSI4 de 64To flambant neuf, mais Quake ne les trouvera pas la ou il s'attend a les avoir! Certes, vous pouvez deplacer Quake en totalite, mais alors les PATHs ne seront plus bons, les menus ne marcheront plus, @#%* de systeme de m...!
Autre exemple: lorsque vous telechargez les sources d'un programme, vous devez le compiler en utilisant le Makefile fourni. La plupart declarent le compilateur cc (commande standard de compilation C sous Unix) mais sous Linux, il faut utiliser gcc. Comme vous n'avez pas envie de devoir corriger systematiquement les Makefiles a la main, vous vous dites qu'il serait bon de pouvoir appeler gcc avec la commande cc. Le renommer est une (tres) mauvaise idee, le copier est encore pire et la possibilite d'ecrire un script shell en faisant attention au bon passage des parametres et a la recuperation des sorties ne vous enchante guere. Alors?

On voit clairement que la gestion de fichiers "normale" est insuffisante et qu'il serait utile, voire indispensable dans certains cas, de pouvoir donner plusieurs noms a un meme fichier ou faire croire qu'il est la ou il n'est pas. Heureusement, et contrairement a certains, Unix nous donne un outil puissant pour nous tirer d'affaire: les liens. Il en existe deux sortes, aux proprietes fondamentalement differentes.

2. Les liens physiques

Ces liens reposent sur la maniere dont Unix gere ses systemes de fichiers. Nous devons nous faire une petite idee de la maniere dont ca marche. Et, pour une fois, la methode Unix est d'une simplicite exemplaire. (A propos, je viens de lire une etude detaillee de la gestion des "noms longs" (=255 caracteres path absolu compris!) sous windoze95... Hilarant!)

A. Le secret des inodes

Un fichier, qui n'est autre chose qu'un ensemble de blocs disque, est associe a un ensemble de parametres appele inode. L'inode contient toutes les informations importantes sur le fichier comme sa taille, son proprietaire, les permissions d'acces etc... Chaque entree de repertoire se compose donc d'une chaine de caracteres donnant le nom du fichier et du numero de bloc contenant l'inode de ce fichier:

(En realite c'est un peu plus complique que ca mais cette fois, on s'en fiche).

Autrement dit, contairement a la FAT sous DOS, Unix ne stocke aucune information sur le fichier autre que son nom dans le repertoire. Vous vous doutez donc certainement de ce que nous allons pouvoir faire: creer plusieurs noms pointant sur le meme inode.

B. Des fichiers a plusieurs noms

Eh bien c'est exactement ca. Faisons quelques essais. Creez un repertoire test et placez dans ce repertoire un fichier, disons par exemple Gill. (Je vous conseille de prendre un fichier texte). Maintenant, entrez la commande suivante:
ln Gill Bates
et affichez le contenu du repertoire. Vous avez maintenant deux fichiers, Gill et Bates, aux contenus identiques, aux dates de creation identiques, bref, indiscernables autrement que par leurs noms. Essayez de modifier Bates et vous voyez que Gill est immediatement affecte par la modification. En effet, les noms Gill et Bates designent effectivement le meme fichier.

Le mecanisme des inodes donne aux liens physiques des proprietes remarquables. Il n'y a pas d'"original" et de "lien", les deux noms du fichier sont parfaitement equivalents. Si vous tapez rm Gill, Bates continue d'exister (et vice versa). Le fichier n'est effectivement detruit que lorsque son inode n'est plus reference par aucun nom.
Une autre caracteristique attrrayante est le fait que le lien n'est jamais rompu. Deplacez Bates ailleurs et vous voyez que le lien continue de fonctionner de maniere totalement transparente. C'est pas beau, ca?
Comme les deux noms (ou plus) utilisent le meme inode, la coherence est totale. Si vous modifiez le proprietaire ou les droits sur le fichier, l'effet sera le meme quel que soit ne nom sous lequel vous accedez au fichier. (C'est beau et elegant, mais c'est une arme en double tranchant: en effet, on peut utiliser cette propriete pour dejouer les barrieres de securite. Un bon sujet d'article dans Line, tiens!)

C. Le revers de la medaille

Tout cela est fabuleux, mais il y a le mauvais cote de la chose. Premierement, ce type de lien ne peut fonctionner qu'au sein d'un meme systeme de fichiers (partition) pour des raisons evidentes. De plus, la transparence est en fait trop parfaite et peut devenir source de confusion. De plus, certains programmes peu intelligents comme cp ne s'en appercoivent pas et copient un fichier en plusieurs exemplaires! (essayez de taper cp -r test test2 et faites un du sur test2!) Heureusement, tar ne se laisse pas avoir.

3. Liens symboliques

Ce type de lien est tres different de ce qui precede. Basiquement, il s'agit d'un fichier contenant un nom de fichier. Reprenons nos fichiers Gill et Bates. Effacez par exemple Bates et tapez:
ln -s Gill Bates
L'option -s indique a ln de creer un lien symbolique. Si vous faites maintenant ls, vous voyez que Bates apparait dans un style different. Tapez ls -l et vous pouvez constater trois choses:

Contrairement au cas des liens physiques, les deux appelations n'ont visiblement pas le meme status: il y a une difference nette entre le "vrai fichier" et les "liens". Si vous essayez de travailler sur le fichier Bates, le systeme sait qu'il doit aller chercher Gill a sa place Gill et Bates peuvent avoir des proprietaires differents, des dates differentes, etc... Toutefois, les droits qui s'appliquent sur un lien symbolique sont toujours ceux du fichier pointe, n'esperez pas prendre possession d'informations confidentielles par cette voie.

Un lien symbolique se comporte de maniere tres differente du lien physique: si vous deplacez ou renommez l'original, le lien est rompu car il est defini par le nom du fichier original. Par contre, vous pouvez sans probleme creer un lien symbolique sur un fichier se trouvant sur une autre partition (avec eventuellement un systeme de fichiers d'une type different).

Il faut bien comprendre que le lien symbolique ne pointe pas sur le fichier cible, mais sur son nom. Si vous effacez Gill, Bates reste la, mais vous ne pouvez plus l'ouvrir. Creez maintenant un autre fichier portant le nom Gill et, o miracle, Bates est a nouveau actif et pointe dessus!

4. Conclusion

Voila, vous savez tout maintenant pour maitriser parfaitement les liens. Vous savez maintenant que vous pouvez deplacer Quake sur une partition et creer un lien (symbolique ou physique?) depuis son emplacement d'origine, afin de preserver la structure de votre arborescence. Alors amusez-vous bien avec ca et attention aux abus!