Comprends les liens et les inodes

L’idée reçue

« Un fichier est son chemin. »

Le chemin est un nom dans un répertoire. L’inode porte les métadonnées et référence les blocs de données. Plusieurs noms peuvent viser le même inode.

01Observe les inodes du laboratoire

cd "$HOME/soria-linux-lab"
ls -li projets/app/data/utilisateurs.txt partage/utilisateurs-hardlink.txt
stat -c 'inode=%i links=%h mode=%A path=%n' projets/app/data/utilisateurs.txt partage/utilisateurs-hardlink.txt

Les deux chemins possèdent le même numéro d’inode et un compteur de liens égal à deux. Ils sont deux noms pour le même objet de données.

02Modifie les données par un autre nom

printf 'delta
' >> partage/utilisateurs-hardlink.txt
tail projets/app/data/utilisateurs.txt

La modification apparaît par les deux chemins, car il n’existe pas deux copies. Le lien physique ne pointe pas vers un nom : il référence le même inode.

03Supprime un nom sans supprimer les données

cp projets/app/data/utilisateurs.txt /tmp/utilisateurs-reference.txt
rm partage/utilisateurs-hardlink.txt
stat -c 'inode=%i links=%h path=%n' projets/app/data/utilisateurs.txt
cat projets/app/data/utilisateurs.txt

Les données restent accessibles tant qu’au moins un nom référence l’inode et qu’aucun processus ne conserve une référence ouverte particulière.

04Observe un lien symbolique

ls -l partage/application.env.link
readlink partage/application.env.link
readlink -f partage/application.env.link
cat partage/application.env.link
stat partage/application.env.link
stat -L partage/application.env.link

Type

Référence

Conséquence

Lien physique

même inode

continue après suppression d’un autre nom

Lien symbolique

texte contenant un chemin

peut devenir cassé

05Crée et répare un lien cassé

mv projets/app/config/application.env projets/app/config/application.env.old

ls -l partage/application.env.link
cat partage/application.env.link || true
find partage -xtype l -print

mv projets/app/config/application.env.old projets/app/config/application.env
cat partage/application.env.link

find -xtype l permet d’identifier les liens symboliques dont la cible ne peut plus être résolue.

Challenge autonome

Conçois un répertoire de versions

Crée trois fichiers de configuration versionnés et un lien symbolique current.conf vers la version active. Change la cible avec ln -sfn, vérifie avec readlink -f et documente pourquoi un lien symbolique convient mieux qu’un hard link dans ce cas.

mkdir -p versions
printf 'version=1
' > versions/app-v1.conf
printf 'version=2
' > versions/app-v2.conf
printf 'version=3
' > versions/app-v3.conf
ln -sfn app-v2.conf versions/current.conf
readlink -f versions/current.conf
cat versions/current.conf

06Nettoie ou réinitialise

./module1-linux-workspace.sh status
./module1-linux-workspace.sh reset

✓Ce que tu retiens

Un chemin n’est pas le fichier lui-même. Les hard links partagent un inode ; les liens symboliques stockent un chemin. Le choix dépend du besoin de portabilité, de lisibilité et du comportement attendu lors des déplacements ou suppressions.