Pourquoi les liens physiques semblent-ils occuper le même espace que les originaux?

Grâce à de bonnes questions et réponses ici et sur cette page , je comprends maintenant les liens. Je vois que les liens matériels font référence au même inode sous un nom différent, et les copies sont des nœuds différents, avec des noms différents. De plus, les liens logiciels ont le nom et le chemin d'origine du fichier comme inode, donc si le fichier est déplacé, le lien se brise.

J'ai donc testé ce que j'ai appris avec un fichier ("saluton_mondo.cpp" ci-dessous), fait un lien dur et un lien doux et une copie.

jmcf125@VMUbuntu:~$ ls -lh soft hard copy s*.cpp
-rw-rw-r-- 1 jmcf125 jmcf125 205 Aŭg 27 16:10 copy
-rw-rw-r-- 2 jmcf125 jmcf125 205 Aŭg 25 13:34 hard
-rw-rw-r-- 2 jmcf125 jmcf125 205 Aŭg 25 13:34 saluton_mondo.cpp
lrwxrwxrwx 1 jmcf125 jmcf125  17 Aŭg 27 16:09 soft -> saluton_mondo.cpp

J'ai trouvé gênant que le lien dur ait cependant la même taille que l'original et, logiquement, la copie. Si le lien dur et l'original partagent le même inode, qui contient les données et ne diffèrent que par le nom de fichier, le lien dur ne devrait-il pas prendre uniquement l'espace de son nom, au lieu de 205 octets? Ou est-ce la taille du fichier d'origine qui ls -lhrevient? Mais alors comment savoir quel espace prend le nom de fichier? Ici, il dit que les liens durs n'ont pas de taille. Leur nom de fichier est-il conservé à côté du nom de fichier d'origine? Où est enregistré le nom de fichier des liens matériels?

Un fichier est un inode avec des métadonnées parmi lesquelles une liste de pointeurs vers où trouver les données.

Pour pouvoir accéder à un fichier, vous devez le lier à un répertoire (pensez aux répertoires comme des répertoires téléphoniques, pas des dossiers), c'est-à-dire ajouter une ou plusieurs entrées à un ou plusieurs répertoires pour associer un nom à ce fichier.

Tous ces liens, ces noms de fichiers pointent vers le même fichier. Il n'y en a pas un qui soit original et les autres qui soient des liens. Ce sont tous des points d'accès au même fichier (même inode) dans l'arborescence des répertoires. Lorsque vous obtenez la taille du fichier ( lstatappel système), vous récupérez des informations (les métadonnées mentionnées ci-dessus) stockées dans l'inode, peu importe le nom de fichier, le lien que vous utilisez pour faire référence à ce fichier .

En revanche, les liens symboliques sont un autre fichier (un autre inode) dont le contenu est un chemin d' accès au fichier cible. Comme tout autre fichier, ces liens symboliques doivent être liés à un répertoire (doit avoir un nom) afin que vous puissiez y accéder. Vous pouvez également avoir plusieurs liens vers des liens symboliques, ou en d'autres termes, les liens symboliques peuvent avoir plusieurs noms (dans un ou plusieurs répertoires).

$ touch a
$ ln a b
$ ln -s a c
$ ln c d
$ ls -li [a-d]
10486707 -rw-r--r-- 2 stephane stephane 0 Aug 27 17:05 a
10486707 -rw-r--r-- 2 stephane stephane 0 Aug 27 17:05 b
10502404 lrwxrwxrwx 2 stephane stephane 1 Aug 27 17:05 c -> a
10502404 lrwxrwxrwx 2 stephane stephane 1 Aug 27 17:05 d -> a

Au-dessus du numéro de fichier 10486707 se trouve un fichier normal. Deux entrées du répertoire courant (une avec le nom a, une avec le nom b) y sont liées. Étant donné que le nombre de liens est 2, nous savons qu'il n'y a pas d'autre nom de ce fichier dans le répertoire en cours ou dans tout autre répertoire. Le fichier numéro 10502404 est un autre fichier, cette fois de type lien symbolique lié deux fois au répertoire courant. Son contenu (cible) est le chemin relatif "a".

Notez que si 10502404 était lié à un autre répertoire que le répertoire actuel, il pointerait généralement vers un fichier différent selon la façon dont il a été accédé.

$ mkdir 1 2
$ echo foo > 1/a
$ echo bar > 2/a
$ ln -s a 1/b
$ ln 1/b 2/b
$ ls -lia 1 2
1:
total 92
10608644 drwxr-xr-x   2 stephane stephane  4096 Aug 27 17:26 ./
10485761 drwxrwxr-x 443 stephane stephane 81920 Aug 27 17:26 ../
10504186 -rw-r--r--   1 stephane stephane     4 Aug 27 17:24 a
10539259 lrwxrwxrwx   2 stephane stephane     1 Aug 27 17:26 b -> a

2:
total 92
10608674 drwxr-xr-x   2 stephane stephane  4096 Aug 27 17:26 ./
10485761 drwxrwxr-x 443 stephane stephane 81920 Aug 27 17:26 ../
10539044 -rw-r--r--   1 stephane stephane     4 Aug 27 17:24 a
10539259 lrwxrwxrwx   2 stephane stephane     1 Aug 27 17:26 b -> a
$ cat 1/b
foo
$ cat 2/b
bar

Les fichiers ne sont associés à aucun nom autre que dans les répertoires qui les lient. L'espace occupé par leurs noms correspond aux entrées de ces répertoires, il est pris en compte dans la taille du fichier / l'utilisation du disque des répertoires.

Vous remarquerez que l'appel système pour supprimer un fichier est unlink. Autrement dit, vous ne supprimez pas les fichiers, vous les dissociez des répertoires dans lesquels ils sont référencés. Une fois dissocié du dernier répertoire contenant une entrée dans un fichier donné, ce fichier est ensuite détruit (tant qu'aucun processus ne l'a ouvert).

Le lien dur est, essentiellement, le fichier d'origine. Ainsi, la taille que vous voyez rapportée est la taille du fichier lié. Ce sont des liens souples qui n'occupent que l'espace de leurs noms (un peu).

En ce qui concerne le système de fichiers, le lien dur et l'original sont la même chose, ils pointent vers le même inode, donc la même taille est indiquée.