Pourquoi les liens durs existent-ils?

Je sais ce que sont les liens durs, mais pourquoi devrais-je les utiliser? Quelle est l'utilité d'un lien dur?

Le principal avantage des liens physiques réside dans le fait qu’il n’existe aucune pénalité de taille ou de vitesse par rapport aux liens symboliques. Les liens symboliques constituent une couche supplémentaire d'indirection en plus de l'accès normal aux fichiers. le noyau doit déréférencer le lien lorsque vous ouvrez le fichier, ce qui prend un peu de temps. Le lien prend également une petite quantité d’espace sur le disque pour contenir le texte du lien. Ces pénalités n'existent pas avec des liens durs car elles sont intégrées à la structure même du système de fichiers.

Le meilleur moyen que je connaisse pour le voir est:

$ ls -id .
1069765 ./
$ mkdir tmp ; cd tmp
$ ls -id ..
1069765 ../

L' -ioption permettant de lsvous donner le numéro d'inode du fichier. Sur le système où j'ai préparé l'exemple ci-dessus, je me trouvais dans un répertoire avec le numéro d'inode 1069765, mais la valeur spécifique importait peu. C'est juste une valeur unique qui identifie un fichier / répertoire particulier.

Ceci dit que lorsque nous allons dans un sous-répertoire et que nous examinons une entrée de système de fichiers différente appelée .., celle-ci a le même numéro d'inode que nous avions auparavant. Cela ne se produit pas car le shell interprète ..pour vous, comme cela se produit avec MS-DOS et Windows. Sur les systèmes de fichiers Unix, il ..y a une entrée de répertoire réelle; c'est un lien dur pointant vers le répertoire précédent.

Les liens physiques sont les câbles qui relient les répertoires du système de fichiers. Il était une fois, Unix n'avait pas de liens durs. Ils ont été ajoutés pour transformer le système de fichiers à plat d’ Unix en un système de fichiers hiérarchique.

(Pour plus d'informations à ce sujet, voir Pourquoi / 'a-t-il une entrée' .. '? .)

Il est également assez courant sur les systèmes Unix que plusieurs commandes différentes soient implémentées par le même exécutable. Il ne semble pas être le cas sous Linux plus, mais sur les systèmes I utilisés dans le passé, cp, mvet rmétaient tout de même exécutable. Cela a du sens si vous y réfléchissez: lorsque vous déplacez un fichier entre des volumes, il s’agit en réalité d’une copie suivie d’une suppression, ce mvqui obligeait déjà à implémenter les fonctions des deux autres commandes. L'exécutable peut déterminer quelle opération à fournir car il reçoit le nom par lequel il a été appelé.

BusyBox est un autre exemple, courant dans les Linux embarqués , un seul exécutable qui implémente des dizaines de commandes.

Je dois souligner que sur la plupart des systèmes de fichiers, les utilisateurs ne sont pas autorisés à créer des liens physiques vers des répertoires. Les entrées .et ..sont automatiquement gérées par le code du système de fichiers, qui fait généralement partie du noyau. La restriction existe car il est possible de causer de graves problèmes de système de fichiers si vous ne faites pas attention à la façon dont vous créez et utilisez les liens physiques d’annuaires. C'est l'une des nombreuses raisons pour lesquelles les liens virtuels existent; ils ne portent pas le même risque.

Une utilisation extrêmement utile des liens physiques est dans les sauvegardes incrémentielles combinées avec rsync. Cela économise beaucoup d'espace et facilite grandement la procédure de restauration. J'utilise cette approche pour la sauvegarde sur mes serveurs.

Prenez le temps de lire cette explication .

Si, après avoir lu cette page wikipedia, votre question est "pourquoi les utiliserais-je jamais", alors vous ne comprenez pas ce que sont des liens physiques.

Un lien est une entrée de répertoire qui pointe vers des blocs sur le disque. En d'autres termes, chaque fichier de votre système a au moins un lien. Lorsque vous rmenregistrez un fichier, l'appel système actuel est unlink(). Il supprime l'entrée du répertoire. Les blocs sur le disque n'ont pas changé mais le lien a disparu, le fichier est donc supprimé de la liste des répertoires.

Personnellement, vous ne pouvez jamais utiliser de liens durs, mais ils sont partout sur votre système. Par exemple:

$ ls -li /bin | grep 53119771
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bunzip2
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bzcat
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bzip2

Vous pouvez voir que bunzip2, bzcatet bziputiliser le même inode. En substance, il s’agit d’un fichier avec trois noms. Vous pourriez avoir trois copies du fichier, mais pourquoi? Cela ne ferait qu'utiliser inutilement de l'espace disque.

Il y a un certain nombre d'utilisations. Je les utilise pour créer des verrous basés sur des fichiers. L'appel système link (2) est atomique, contrairement à la plupart des autres appels système.

Une autre utilisation est dans rsnapshot, où les sauvegardes sont effectuées au fil du temps en utilisant des liens physiques pour réduire la quantité d'espace disque. Si un fichier n'a pas changé, alors le fichier est lié en dur aux anciennes instances du fichier. Les fichiers modifiés sont à nouveau copiés.

Je les utilise également pour échanger des fichiers de configuration sur des serveurs: les fichiers rm file.cfg && ln ~/tmp/file.cfg file.cfg~ / tmp / * peuvent ensuite être supprimés en toute sécurité.

Pour ajouter aux nombreuses bonnes discussions déjà présentes ...

• La manière dont l’accès aux ressources pour les programmes est implémenté sous unix (c’est-à-dire que "tout est un fichier" ) signifie que l’infrastructure permettant de gérer plusieurs références à un fichier est nécessaire au bon fonctionnement du système d’exploitation. Il n’ya donc aucun coût supplémentaire à supporter ici.
• Les répertoires de manière ont été mises en œuvre dans les systèmes de fichiers unix d' origine ( à savoir une liste de format fixe de (inode, name)paires signifie qu'il n'y a pas de frais supplémentaires dans le système de fichiers ayant des liens physiques (bien, aussi longtemps que nous empêchons cycles en prohibant hardlinke aux répertoires (autres que .et ..(Est-ce que cela commence à ressembler à un feu follet à quelqu'un d'autre?))

alors nous les obtenons gratuitement.

Je devrais probablement couvrir un scénario de piège de liens durs. Un lien physique sera simplement le même fichier avec un nom différent et / ou un emplacement différent tant que le fichier lié original existe . Il n'est même pas correct de penser que le fichier est "original": les deux sont des entrées de répertoire de plein droit, et les deux (ou plus) sont des pairs égaux. Pour les fichiers de longue durée, cela peut être une bénédiction, mais si l’un des couples est supprimé, puis créé, même avec le même nom et le même contenu, les fichiers seront séparés.

Supposons que vous créiez un /foo/myfilelien physique vers /repo/myfile. Les deux sont des pointeurs sur les mêmes données de fichier; changer un, les autres changements. Mais supposons que /repocela arrive à contenir un dépôt Git. Si vous extrayez une branche qui n'en contient pas myfile, /repo/myfileest supprimée. En ce moment, /foo/myfiledevient une simple copie de /repo/myfile, pour ainsi dire, l’autre de la paire était non liée. Il est facile de ne pas remarquer que vous changez de branche lorsque vous modifiez le répertoire de fichiers, mais lorsque vous extrayez la branche originale, un nouveau fichier/repo/myfileest créé par Git. Si vous n'y faites pas attention, vous vous demanderez pourquoi les deux fichiers ont maintenant un contenu différent, bien qu'il soit facile de s'en emparer, car la relation de liaison matérielle entre les fichiers n'a aucune idée de leur nom. Un lien symbolique, au contraire, survivrait à travers ce cycle de suppression-création.

Par contre, les logiciels qui utilisent des liens durs en sont très conscients, et Git en est un excellent exemple. Git clone un dépôt sur le même système de fichiers presque gratuitement, car il utilise des liens physiques par défaut au lieu de copier des fichiers. Pour Git, le lien physique est un cas d'utilisation idéal, car ses fichiers d'objet et de pack ne changent jamais. Par conséquent, un clone du référentiel ne modifiera jamais l'autre (Git ne sait pas relier en dur des fichiers modifiables), et n'importe lequel des clones peut être supprimé sans aucune précaution: il n'est pas nécessaire de savoir lequel est l'original et contient réellement les fichiers: l'un des liens physiques est un partenaire égal et "contient" le fichier complet. Les liens symboliques ne fonctionneraient tout simplement pas ici.

Un autre avantage du lien physique réside dans le fait que tout lien peut être déplacé sans interrompre l'accès au contenu du fichier. Avec les liens symboliques, le déplacement du fichier d'origine rend tous les liens dynamiques pendants.

L’essentiel est que, dans de nombreux cas d’utilisation, l’un ou l’autre type de lien fonctionne également, mais qu’un type ou un autre est avantageux. L’efficacité, mentionnée dans de nombreuses réponses ici, ne concerne probablement que très peu les machines et les systèmes de fichiers modernes, à moins que vous ne nettoyiez un système de fichiers sur une puce FLASH d’un mauvais contrôleur embarqué. Les différences fonctionnelles sont plus importantes et dictent généralement les contraintes techniques et le choix ultime:

• Le lien physique "source" peut être déplacé en toute sécurité, tandis que le lien symbolique va se rompre.
• Le lien physique ne peut pas être distingué du fichier auquel il était lié, et le fichier est actif aussi longtemps que l'un des liens matériels est actif. le lien souple est asymétrique.
• L'homologue lié durement se sépare du groupe lié s'il est supprimé et recréé, mais le lien souple ne perd pas sa cible.
• Le lien symbolique peut traverser des systèmes de fichiers, pas le lien physique.
• Le lien symbolique peut pointer vers un répertoire, le lien physique ne le peut généralement pas (et ne devrait pratiquement pas toujours).

De plus, je dois signaler que l'appel de la bibliothèque qui supprime un fichier est appelé unlink()pour une raison! Chaque entrée de répertoire est juste un lien dur au départ singulier vers son inode.