PROJET AUTOBLOG


Shaarli - Les discussions de Shaarli

Archivé

Site original : Shaarli - Les discussions de Shaarli du 23/07/2013

⇐ retour index

Note : les liens sous Linux/Unix

lundi 20 avril 2015 à 18:43
le hollandais volant 20/04/2015
(Ceci est une note à moi, concernant Linux. Je me met ça là pour avoir une vision plus claire des choses. Ça peut peut-être en aider d’autres)


Sous Linux, il existe des liens entre les fichiers. Un peu comme les raccourcis Windows.

Il y a deux types de liens :
— les liens en dur (hardlink, obtenus par la commande « ln file1 file2 »)
— les liens symboliques (softlink ou symlink, obtenus par la commande « ln -s file1 linkToFile1 »)

En images :
Lien en dur : https://upload.wikimedia.org/wikipedia/commons/3/32/Hard_Link_Illustration.svg
Lien symbolique : https://upload.wikimedia.org/wikipedia/commons/2/24/Symlink_concept.png?uselang=fr (ignorez la case "inode")

Je note déjà qu’un nom de fichier n’est en fait lui-même qu’un lien en dur vers les données sur le disque.

1) Le lien en dur
Le lien en dur de « file2 » vers « file1 » n’est pas un pointeur qui pointe de file2 à file1. Les deux fichiers pointent en fait vers les mêmes données sur le disque.
Il y a juste deux « portes d’accès » vers ces données, que sont file1 et file2.
Ces dernières sont indépendantes : déplacer file1 ne rendra pas mort le lien en dur file2

Si vous ouvrez le fichier file2 et que vous le modifiez, alors il modifiera les fichiers sur le disque. Le fichier file1 affichera également les changements.

Si on supprime un des liens en dur, les données ne sont pas supprimés sur le disque : les autres liens en dur fonctionneront toujours également.
Les données ne sont supprimés du disque que si tous les liens en dur sont supprimés (En réalité l’espace occupé par les données n’est pas remis à zéro, il est marqué comme « accessible » pour de futures nouvelles données).

Si on écrase file1 par un autre fichier du même nom (par exemple avec "mv file3 file1"), alors le fichier file1 contiendra les données de file3. Mais file2 ne sera pas modifié.

2) Le lien symbolique
Le lien symbolique de « file2 » vers « file1 » est un pointeur de file2 vers file1. Le fichier « file2 » vas pointer vers « file1 » qui va pointer vers les données sur le disque.

Si on ouvre le lien file2, le noyau Linux va interpréter ça comme « c’est un lien vers file1, donc j’ouvre file1 ». Les modifications seront visibles sur le disque depuis les deux fichiers file1 et file2.

Supprimer le lien file2 ne touchera pas à file1 ni aux données sur le disque.
Supprimer le fichier file1, le lien file2 sera « mort » et les données seront supprimées sur le disque.

3) différence entre lien en dur et la copie
Quand on copie un fichier, on le copie sur le disque : modifier l’un ne modifiera pas le second.
Le lien en dur c’est deux noms pour le même fichier sur le disque. Comme deux portes d’accès.



Pour résumer
— Copies : deux noms de fichiers, deux fichiers indépendants, deux fois les données sur le disque.
— Lien dur : deux noms de fichiers, deux fichiers identique, une fois les données sur le disque.
— Lien sym. : un lien pointant vers le fichier et dépendant de ce fichier. Une seule fois les données sur le disque.

Le lien en dur est utile si on a besoin d’accéder au même données sur le disque sous plusieurs noms de fichiers.
Le symbolique a son intérêt

Le lien en dur ne fonctionne pas avec les dossiers : du point de vue du disque dur, un dossier n’est rien du tout. C’est juste un moyen pour le système de fichier d’organiser les fichiers.
Quand on déplace un fichier d’un dossier à un autre, ce n’est que l’index dans le système de fichier qui est modifié : les données binaires sur le disque restent au même endroit (c’est pour ça que le déplacement de fichiers est très rapide, même si le fichier fait 5 Go).

Liens > le hollandais volant 21/04/2015
Quelques remarques.

- Si on lance un ls -i sur deux noms de fichiers pointant vers le même fichier réel (donc un lien dur), on obtient le même inode : c'est l'identifiant du fichier sur le disque. Ce n'est pas le cas dans le cas d'un lien soft.
- Etant donné que le lien dur fonctionne sur l'inode, il est impossible de réaliser un lien dur d'un FS vers un autre.
- Si on lance un ls -l, le deuxième champ indique le nombre de liens durs existants sur le fichier en question. Mais pourquoi un répertoire a-t-il un nombre supérieur à 1 alors qu'on ne peut pas faire de lien dur entre répertoires ? Parce que le système se fait quand même des liens durs de lui-même. Si vous faites ls -a dans un répertoire, vous verrez "." ("moi"), et ".." ("mon parent"). Ce sont deux liens durs. Donc, simplement en regardant ce nombre, vous savez combien le répertoire contient de sous-répertoires (le nombre - 2).


"""Je note déjà qu’un nom de fichier n’est en fait lui-même qu’un lien en dur vers les données sur le disque."""
> Oui

"""
Si on supprime un des liens en dur, les données ne sont pas supprimés sur le disque : les autres liens en dur fonctionneront toujours également.
Les données ne sont supprimés du disque que si tous les liens en dur sont supprimés (En réalité l’espace occupé par les données n’est pas remis à zéro, il est marqué comme « accessible » pour de futures nouvelles données).
"""
> C'est même encore plus subtil que ça. Si le fichier est ouvert dans un programme, il n'est pas supprimé lorsqu'on lance la commande "rm". C'est parce que le programme qui utilise un fichier crée un lien vers ce fichier. Le fichier n'est supprimé du disque (ou marqué comme accessible) que lorsqu'il n'y a plus aucun lien vers le fichier, donc lorsqu'il n'y a plus de nom de fichier dans le FS, et que tous les programmes qui l'avaient ouvert l'ont fermé.

Il existe d'ailleurs, dans tout langage de programmation sérieux, un moyen de créer des "fichiers sécurisés". Ce sont des fichiers créés avec un nom aléatoire, et supprimés aussitôt du disque (ou alors même pas créés avec un nom). Le programme garde un pointeur sur le fichier qui existe alors toujours sur le disque, mais devient inaccessible via le FS. Quand l'application se ferme, le fichier est "supprimé".
(Permalink)