Comment Linux fonctionne-t-il avec les liens symboliques?

Je veux dire ce qui se passe quand un processus veut lire un lien symbolique? Que se passe-t-il lorsque quelque chose change un lien symbolique pendant un processus de lecture ou même d'écriture?

Par exemple: j'ai 2 énormes fichiers 100G similaires /mnt/1et /mnt/2. /mnt/1est disponible via le lien symbolique /home/user/file. Certains programmes Acommencent à lire /home/user/file. Et après un moment, quelque chose change le lien de /mnt/1en /mnt/2, mais Alit toujours le fichier.

Le programme met-il en cache le chemin absolu?

Va-t-il échouer et commettre une erreur, car le lien symbolique a été modifié ou fonctionnera-t-il correctement, comme si rien ne s'était passé?

Sera-t-il différent dans le cas où il /home/user/fileest lié à un périphérique bloc (par exemple 2 disques iscsi répliqués)?

Le lien symbolique pointe vers le nom du fichier réel ( inode ) dans le système de fichiers. Lorsque le système résout ce lien symbolique pour trouver le fichier réel et l'ouvrir, il recherche et utilise l'inode du fichier. À ce stade, le chemin d'accès que vous avez utilisé pour accéder au fichier n'a pas d'importance. Ce que l'OS ne met pas en cache, il lit le fichier par son inode. Si je comprends bien, vous pouvez commencer à lire le fichier via un lien dur et supprimer ce lien dur (tant que le fichier est toujours lié ailleurs) , et cela ne causerait pas de problèmes tant que le fichier a été résolu ( nom chaîne-> inode).

Un lien symbolique est un petit fichier qui contient l' emplacement (c'est-à-dire le chemin et le nom de fichier) d'un fichier cible, avec un indicateur dans l'entrée de répertoire indiquant qu'il s'agit d'un lien symbolique.

Lorsque vous ouvrez un lien symbolique, le système d'exploitation suivra l'emplacement pour trouver le fichier cible. Si la cible est elle-même un lien symbolique, elle suit également son emplacement (1) (2) jusqu'à ce que l'emplacement pointe vers un fichier qui n'est pas un lien symbolique (appelons-le FinalFile ). Ensuite, le système d'exploitation obtient l' inode du FinalFile (l'inode contient des métadonnées comme le temps de modification et a également un pointeur vers les données du fichier). Enfin l'inode du FinalFile est ouvert. Désormais, le processus utilise cet inode pour lire / écrire dans le fichier. En conséquence, changer le nom ou le chemin du lien symbolique, supprimer le lien symbolique, changer le chemin ou le nom du fichier final ou même supprimer le fichier final(3) n'a aucun effet sur le processus; il lit toujours depuis le même inode.

Dans la plupart des cas, les opérations sur les données du fichier sur le lien symbolique affecteront le fichier final (par exemple, la lecture et l'écriture sur le lien symbolique lira / écrit dans le fichier final ) mais il y a des exceptions: l' readlink()appel système lit le contenu du lien symbolique lui-même.

Les opérations de métadonnées de fichier (comme renommer ou supprimer), d'autre part, affectent généralement le lien symbolique. Mais il y a des exceptions ici aussi: l' lstat()appel système est similaire stat(), sauf qu'il renvoie des informations sur le lien symbolique lui-même plutôt que sur le FinalFile (2).

(1) Il y a une limite sur le nombre de niveaux et les choses deviennent un peu plus complexes si l'emplacement dans le lien symbolique est un chemin relatif.

(2) Lire le lien symbolique (7): gestion des liens symboliques pour plus de détails.man 7 symlink

(3) La rmcommande ou l' unlink()appel système ne supprime pas physiquement un fichier. Il supprime l'entrée de répertoire qui pointe vers l'inode du fichier. Le fichier lui-même n'est supprimé que si les deux a) il n'y a plus d'entrées de répertoire (liens durs) faisant référence à son inode et b) aucun processus n'a ouvert le fichier.

C'est presque transparent pour Linux, et il est beaucoup plus lié au système de fichiers que vous utilisez qu'au système d'exploitation.

Ce n'est pas un fichier normal ou un très petit fichier car vous ne pouvez pas créer un lien symbolique de travail dans une partition VFAT par exemple en copiant simplement le lien symbolique lui-même, car il est enregistré directement par le système de fichiers.

La différence dans le lien symbolique vers un lien dur est que le rendez-vous se fait vers un lien dur au lieu de poiter vers les secteurs de données comme le fait un lien dur.

Exemple:

Test 1:

echo 'data' >file.txt

Cela créera le fichier de lien dur file.txt pointant vers les secteurs 10 à 20 * (* chiffres juste pour expliquer).

Test 2:

Et si maintenant?

ln file.txt file_2.txt

Cela a créé un lien dur file_2.txt pointant vers les secteurs 10 à 20 (le même que file.txt), donc si vous supprimez file.txt, les secteurs 10 à 20 sont toujours réservés, et vous pouvez voir les données dans file_2.txt ... . (file.txt et file_2.txt sont tous deux comme les originaux)

Test 3:

ln -s file.txt file_sym.txt 

Lien symbolique pointé file_sym.txt vers le lien dur file.txt, donc quand vous essayez d'accéder à file_sym.txt vous verrez file.txt, mais si vous supprimez file.txt file_sym ne trouvera plus la cible.

Ceux-ci sont gérés par le système de fichiers, par exemple par les modules ext4 pour linux (ou s'il est compilé sur le noyau), peu importe si vous utilisez Linux ou un autre Unix.