Liens symboliques, hard links et jonctions : comprendre NTFS et Linux

Les liens symboliques, hard links et jonctions permettent à plusieurs chemins de conduire vers les mêmes données sans devoir nécessairement les dupliquer. Ils sont utilisés pour organiser des arborescences, conserver des chemins historiques, partager un même fichier entre plusieurs emplacements ou déplacer certaines ressources sans modifier toutes les applications qui les utilisent.

Mais derrière le mot « lien » se cachent plusieurs mécanismes très différents. Un lien symbolique mémorise essentiellement un chemin. Un hard link ajoute un nouveau nom au même fichier. Et sous Windows, les junctions forment encore une troisième famille destinée aux répertoires.

La question essentielle est simple : le lien référence-t-il un autre nom, ou référence-t-il directement le même objet du système de fichiers ?

Hard link et lien symbolique : la différence fondamentale

Imaginons un fichier nommé rapport.txt. Avec un lien symbolique, on crée un second objet contenant essentiellement l’information « lorsque quelqu’un m’ouvre, allez chercher rapport.txt à tel endroit ».

Si la cible est déplacée ou supprimée, le lien symbolique peut rester présent mais ne mène plus nulle part. On parle alors de lien cassé ou de dangling symlink.

Un hard link fonctionne autrement. Deux noms de fichiers désignent directement le même objet du système de fichiers. Il n’existe donc pas réellement de hiérarchie entre « original » et « hard link ».

Propriété	Lien symbolique	Hard link
Référence	Un chemin	Le même objet de fichier
Possède sa propre entrée	Oui	Oui, comme autre nom du même fichier
Peut devenir cassé	Oui	Non tant qu’un lien vers le fichier subsiste
Peut traverser un système de fichiers	Oui	Non
Peut viser un répertoire	Oui	Normalement non

Cette distinction explique pourquoi supprimer « l’original » d’un hard link ne détruit pas nécessairement les données. Vous avez simplement supprimé l’un de leurs noms.

Sous Linux : inode, noms de fichiers et compteur de liens

Sur un système de fichiers Unix classique comme ext4, une entrée de répertoire associe essentiellement un nom à un inode. L’inode contient les métadonnées du fichier et les informations permettant au système de retrouver ses données.

Créons un fichier :

echo "Serveur opérationnel" > rapport.txt
ls -li rapport.txt

L’option -i affiche son numéro d’inode.

Créons maintenant un hard link :

ln rapport.txt rapport-copie.txt
ls -li rapport.txt rapport-copie.txt

Les deux noms affichent le même numéro d’inode. Modifier l’un modifie donc immédiatement ce que l’on voit depuis l’autre :

echo "Nouvelle ligne" >> rapport-copie.txt
cat rapport.txt

Si l’on supprime le premier nom :

rm rapport.txt
cat rapport-copie.txt

le fichier reste parfaitement accessible par rapport-copie.txt.

Le système maintient notamment un compteur de liens. Il est visible dans la seconde colonne de :

ls -l rapport-copie.txt

Un hard link doit rester sur le même système de fichiers. Cette commande échouera donc si les deux chemins se trouvent sur des systèmes de fichiers différents :

ln /home/user/fichier.txt /mnt/autre-disque/fichier.txt

La raison est structurelle : les références internes comme les numéros d’inode ne constituent pas un mécanisme de liaison global entre plusieurs systèmes de fichiers.

Créer un lien symbolique sous Linux

La syntaxe est :

ln -s cible lien

Exemple :

ln -s /srv/documents/rapport.txt ~/rapport.txt

Pour un répertoire :

ln -s /srv/projets ~/projets

Contrairement au hard link, la cible n’a même pas besoin d’exister lors de la création :

ln -s /srv/futur/fichier.txt lien.txt

Le lien devient utilisable si cette cible apparaît ultérieurement.

Pour connaître sa destination :

readlink lien.txt
readlink -f lien.txt

Sous Windows : hard links, symlinks et junctions

NTFS possède plusieurs mécanismes qui remplissent des rôles similaires sans être identiques.

Type Windows	Fichier	Répertoire	Autre volume	Cible réseau
Hard link	Oui	Non	Non	Non
Symbolic link	Oui	Oui	Oui selon le chemin	Possible avec une cible UNC
Junction	Non	Oui	Oui, localement	Pas comme une cible réseau classique

Hard links NTFS

Un fichier NTFS est représenté dans la Master File Table, ou MFT. Plusieurs noms peuvent référencer le même fichier dans un même volume.

Avec CMD :

mklink /H "C:\Projet\rapport.txt" "C:\Commun\rapport.txt"

Les deux chemins donnent alors accès au même contenu.

Pour afficher les hard links associés à un fichier :

fsutil hardlink list "C:\Projet\rapport.txt"

On peut également créer un hard link directement avec :

fsutil hardlink create "C:\Projet\rapport.txt" "C:\Commun\rapport.txt"

Impossible en revanche de créer un hard link entre :

C:\fichier.txt et D:\fichier.txt, même si les deux disques se trouvent physiquement dans le même ordinateur.

Liens symboliques NTFS

Pour un fichier :

mklink "C:\Liens\rapport.txt" "D:\Documents\rapport.txt"

Pour un répertoire :

mklink /D "C:\Liens\Documents" "D:\Documents"

NTFS implémente notamment les symlinks grâce aux reparse points. Le système rencontre le lien pendant la résolution du chemin et applique les informations de redirection qui lui sont associées.

Les liens peuvent être relatifs ou absolus. Un lien symbolique Windows peut aussi viser une cible réseau UNC appropriée, ce qui le distingue d’une junction.

La création de symlinks peut nécessiter le droit Windows correspondant. Sur les versions modernes de Windows, le Developer Mode permet notamment à des outils compatibles de créer des liens symboliques sans élévation administrative.

Les junctions

Une junction est une forme de reparse point utilisée pour rediriger un répertoire vers un autre répertoire local.

mklink /J "C:\Archives" "D:\Archives"

Elle peut donc relier deux volumes locaux différents. Elle ne sert en revanche pas à créer un hard link de répertoire et ne constitue pas l’équivalent exact d’un symlink POSIX.

Windows utilise lui-même largement les reparse points et junctions pour assurer certaines compatibilités historiques.

Commandes utiles sous Windows et Linux

Action	Windows CMD	Linux
Symlink vers fichier	mklink lien.txt cible.txt	ln -s cible.txt lien.txt
Symlink vers dossier	mklink /D lien cible	ln -s cible lien
Hard link	mklink /H lien.txt cible.txt	ln cible.txt lien.txt
Junction	mklink /J lien cible	Pas d’équivalent exact
Voir les hard links	fsutil hardlink list fichier.txt	ls -li fichier.txt
Lire la cible d’un symlink	dir /AL	readlink lien
Supprimer lien vers fichier	del lien.txt	rm lien.txt
Supprimer lien vers dossier	rmdir lien	rm lien

PowerShell prend également en charge ces objets directement :

New-Item -ItemType SymbolicLink -Path .\lien.txt -Target .\cible.txt
New-Item -ItemType HardLink -Path .\copie.txt -Target .\cible.txt
New-Item -ItemType Junction -Path C:\Archives -Target D:\Archives

Cas pratiques et pièges courants

Partager un fichier sans le dupliquer

Un hard link est particulièrement intéressant lorsque deux chemins du même système de fichiers doivent réellement représenter le même fichier.

Sous Linux :

ln /srv/commun/config.ini /srv/application/config.ini

Sous Windows :

mklink /H "C:\Application\config.ini" "C:\Commun\config.ini"

Une modification effectuée via n’importe lequel des deux noms modifie le même fichier. Ce n’est pas une synchronisation : il n’y a qu’un seul contenu.

Rediriger un ancien chemin

Un symlink est plus approprié lorsqu’une application continue d’attendre un ancien emplacement.

ln -s /srv/nouveau/emplacement /opt/application/data

Sous Windows :

mklink /D "C:\Application\Data" "D:\Data"

Cette technique peut éviter de modifier une application ancienne, mais elle doit être testée : certains logiciels, outils de sauvegarde ou mécanismes de sécurité traitent les reparse points et symlinks de manière particulière.

Déplacer /var/log

Déplacer brutalement `/var/log` pendant que le système fonctionne n’est pas recommandé. Des processus peuvent déjà posséder des fichiers ouverts dans cette arborescence.

Pour une migration planifiée, on peut arrêter les services concernés puis copier les données vers un nouveau système de fichiers. Pour un stockage permanent séparé, un montage direct ou un bind mount est souvent plus propre qu’un symlink.

Exemple de bind mount temporaire :

mount --bind /mnt/logs /var/log

Pour rendre cette organisation permanente, elle doit ensuite être configurée proprement dans `/etc/fstab` après validation.

Attention aux boucles

Les liens symboliques permettent de construire involontairement des cycles :

mkdir a b
ln -s ../b a/b
ln -s ../a b/a

Un programme qui suit récursivement les liens sans protection pourrait alors tourner en rond. Les outils modernes possèdent généralement des mécanismes de détection ou choisissent de ne pas suivre les symlinks par défaut, mais chaque logiciel doit être vérifié.

Sauvegardes, permissions et suppressions : là où commencent les surprises

Les outils de sauvegarde doivent décider s’ils enregistrent le lien lui-même ou le contenu de sa cible. Cette distinction est importante : suivre tous les liens peut provoquer des duplications massives, sortir de l’arborescence prévue ou créer des boucles.

Les hard links posent un autre problème : un outil naïf peut sauvegarder plusieurs fois le même contenu alors que plusieurs noms correspondent au même fichier. Les logiciels de sauvegarde sérieux savent généralement préserver ou détecter les hard links, mais il ne faut pas le supposer sans vérifier.

Les permissions méritent également de l’attention. Deux hard links partagent le même objet et donc ses données et métadonnées fondamentales. Changer le contenu ou les droits du fichier via l’un des noms affecte le même fichier.

Un symlink possède au contraire sa propre existence dans l’espace de noms, puis la résolution du chemin conduit vers la cible. Les contrôles d’accès doivent donc tenir compte du chemin parcouru et de l’objet réellement atteint.

Un lien ne contourne pas magiquement les permissions. Mais une application qui gère mal les symlinks peut parfois être amenée à travailler sur un fichier qu’elle ne pensait pas viser.

C’est notamment pourquoi les liens symboliques sont importants dans la sécurité des applications manipulant des fichiers temporaires, des archives ou des répertoires accessibles à plusieurs utilisateurs.

Quel type de lien choisir ?

Besoin	Choix généralement adapté
Même fichier sous plusieurs noms sur le même système de fichiers	Hard link
Pointer vers un fichier situé ailleurs	Symlink
Pointer vers un autre système de fichiers Linux	Symlink
Rediriger un répertoire Windows vers un autre volume local	Junction ou symlink selon le besoin
Pointer vers une ressource UNC sous Windows	Symlink lorsque le contexte le permet
Déplacer durablement un gros répertoire système Linux	Montage dédié ou bind mount souvent préférable

Il faut également retenir qu’un lien symbolique Windows n’est pas un raccourci `.lnk`. Le raccourci utilisé par l’Explorateur est un fichier interprété principalement par le shell graphique ; un symlink appartient au mécanisme de résolution du système de fichiers et peut être suivi directement par les applications compatibles.

Conclusion : plusieurs noms, mais pas la même magie

Le principe peut être résumé simplement : un symlink pointe vers un chemin, un hard link donne un autre nom au même fichier.

Sous Linux, cette différence apparaît clairement entre l’inode partagé des hard links et l’objet distinct contenant le chemin d’un symlink. Sous NTFS, le principe est comparable pour les hard links, tandis que les reparse points permettent à Windows d’implémenter symlinks et junctions.

Le hard link est idéal lorsque plusieurs noms doivent vraiment désigner le même fichier sans duplication. Le symlink est plus flexible : il peut viser des répertoires et traverser des systèmes de fichiers. La junction Windows constitue quant à elle une solution historique et encore très utile pour rediriger des répertoires locaux.

Ces mécanismes sont extrêmement pratiques, mais ils modifient une hypothèse que beaucoup de programmes et d’humains font inconsciemment : un chemin correspond à un objet unique situé exactement à cet endroit.

Dès que les liens entrent en scène, l’arborescence devient un peu moins géographique et beaucoup plus philosophique.

Ce qui est excellent pour l’administrateur système.

Un peu moins pour celui qui doit comprendre la sauvegarde laissée par son prédécesseur.