Quand la création d'un lien dur serait-elle utile?

Il existe essentiellement deux limitations principales avec les liens durs:

1. Les liens matériels nécessitent normalement que le lien et le fichier résident dans le même système de fichiers.
2. Seul le superutilisateur peut créer un lien dur vers un répertoire.

Ainsi, des liens symboliques ont été introduits pour contourner les limites des liens durs. La question est donc de savoir si des liens durs sont encore nécessaires? Pourrait-il y avoir une situation où ils sont plus utiles?

Les liens physiques nous aident à organiser notre système de fichiers de manière beaucoup plus flexible. Fondamentalement, les liens physiques nous permettent de prendre un fichier et de l'avoir à plusieurs endroits à la fois dans le système de fichiers. Pensez à un scénario où vous êtes photographe et avez beaucoup de photos (ceci est un exemple de ma vie!). Vous pouvez les organiser par les personnes qui y apparaissent, car parfois les gens vous demandent des photos d'eux. Mais vous voudrez peut-être aussi les organiser par lieu et par date. Il n'y a pas vraiment de moyen d'imbriquer ces trois choses, ce sont des axes d'organisation totalement séparés. Vous pouvez donc créer trois hiérarchies différentes pour ces trois choses différentes, et avoir chaque photo présente dans les trois, sansavoir à stocker chaque photo trois fois. C'est la magie des liens physiques. Dissociez les liens symboliques, nous n'avons pas à nous soucier de l'emplacement du "vrai fichier", car ils sont tous le vrai fichier. Nous pouvons supprimer et déplacer à volonté, car le fichier sera conservé jusqu'à ce qu'il n'y ait plus de références, et supprimé lorsque vous supprimez le dernier lien dur. C'est simple et ne vous oblige pas à garder une trace de beaucoup.

Le contenu d'un fichier ne sera pas purgé tant que tous les liens durs (oui, tous les noms de fichiers ne sont pas des liens durs, même le premier) ont été effacés et le fichier fermé. En tant que tel, il peut être utile lorsqu'un fichier est requis à plusieurs endroits, mais peut être supprimé de n'importe lequel d'entre eux à tout moment, par exemple entre ~/Downloads/coolsong.mp3et ~/Music/Cool Song.mp3.

Un avantage pas très important d'un lien dur sur un lien symbolique est que lorsqu'il atteint l'inode d'un lien dur, le noyau n'a plus de traitement à faire pour accéder au fichier. Lorsqu'il rencontre un lien symbolique, le noyau doit lire la valeur du lien et continuer à parcourir la structure de répertoires avant d'arriver à l'inode du fichier. Cela prend plus de temps, bien que la différence ne soit pas nécessairement facilement mesurable. Cela devient vraiment amusant quand l'un des éléments de la valeur du lien symbolique est lui-même un lien symbolique.

il existe plusieurs raisons pour les liens physiques

1. conserver les références à un fichier jusqu'à ce que la dernière référence soit disparue (comme l'a souligné Ignacio)
2. lorsque vous liez des fichiers en dur, ils n'occupent que l'espace d'un fichier dans le système de fichiers (les deux références au fichier partagent les mêmes i-nœuds). Les liens physiques doivent donc se trouver sur le même système de fichiers.

Donc, une raison d'utiliser des liens physiques est de gagner éventuellement beaucoup d'espace ...

Vous pouvez ajouter à l'une des références et les données vont dans le fichier partagé. Vous pouvez également ajouter à un descripteur de fichier lors de la lecture de l'autre (par exemple avec tail -f)

De nombreux exemples donnés ici sont valables, mais fonctionneraient tout aussi bien avec des liens logiciels (par exemple, le problème "besoin d'un fichier à plusieurs endroits").

Un bon exemple pour lequel les liens durs sont vraiment utiles est le logiciel de sauvegarde Dirvish :

Dirvish est un système de sauvegarde réseau rapide, basé sur disque et rotatif.

Avec dirvish, vous pouvez conserver un ensemble d'images complètes de vos systèmes de fichiers avec une création et une expiration sans assistance. Un coffre-fort de sauvegarde dirvish est comme une machine à remonter le temps pour vos données.

Dirvish crée des sauvegardes au niveau du système de fichiers (c'est-à-dire qu'il copie des fichiers, il ne crée pas d'images), en copiant des fichiers sur un système de fichiers (de sauvegarde) séparé (tel qu'un disque dur USB). Chaque fois que vous effectuez une sauvegarde, dirvish créera une copie complète et distincte de l'arborescence de répertoires à enregistrer.

L'astuce est que si dirvish détecte qu'il existe déjà une copie de sauvegarde plus ancienne de l'arborescence que vous enregistrez, il réutilisera automatiquement les fichiers qui n'ont pas changé, en créant un lien dur dans la nouvelle arborescence avec le fichier de l'ancienne arborescence.

De cette façon, chaque copie de sauvegarde est une copie complète et autonome de l'arborescence de répertoires, mais en même temps, seuls les fichiers modifiés prennent réellement de la place dans le système de fichiers. En d'autres termes, vous bénéficiez à la fois des sauvegardes incrémentielles (économie d'espace) et des sauvegardes complètes (récupération facile).

Cela n'est possible que parce que les liens physiques sont complètement transparents pour les outils de l'espace utilisateur.

Cela fonctionnerait probablement aussi avec les liens symboliques (bien que vous rencontriez des problèmes lors de la sauvegarde de données qui utilisent des liens symboliques eux-mêmes), mais un avantage uniquement possible avec les liens matériels est:

Si vous souhaitez supprimer les anciennes sauvegardes, vous pouvez simplement supprimer l'arborescence de répertoires de sauvegarde correspondante. Les fichiers uniquement liés à partir de cette arborescence sont supprimés automatiquement par le système de fichiers (car leur dernier lien dur est supprimé), mais les fichiers qui apparaissent également dans d'autres copies restent sur le disque.

Un cas utile est, par exemple, lorsque vous avez un programme (ou script) qui doit télécharger une grande archive temporaire et après l'avoir extrait, votre programme le supprimera immédiatement.

Si, pour une raison quelconque, vous souhaitez conserver cette archive tar pour une utilisation future, la meilleure façon de le faire ln /tmp/tarball.tgz ~pendant que l'archive est toujours en cours de téléchargement. Ensuite, vous n'avez rien à faire.

Une fois le téléchargement terminé, et même après que votre programme a supprimé l'original, la copie exacte doit toujours se trouver dans votre répertoire personnel.

J'utilise des «liens durs» pour sauvegarder certains de mes «HowTos» et extraits de code

J'ai un répertoire nommé «Documents partagés» dans mon utilisateur / racine. Dans ce répertoire, j'ai des «liens durs» vers mes trucs, astuces, extraits, comment faire qui vivent dans leurs répertoires appropriés; php, mysql, css, regex, formules, linux, etc., Les avoir en un seul endroit le rend beaucoup plus facile à utiliser, les mettre à jour que d'avoir à parcourir mes documents / répertoires à la recherche de ces documents que j'utilise souvent.

Il y a longtemps, j'ai utilisé des liens symboliques. Je sauvegarderais fidèlement ce répertoire commun de "Documents partagés" sur mon serveur. Le problème est, les liens symboliques ou les «liens souples», s'ils sont copiés (cp -auv) ou tarés et copiés, SEULEMENT sauvegarder ou copier le «lien» et NON le contenu du document. Donc, je devrais parcourir les répertoires et copier chacun des 2 douzaines de fichiers à partir de leur emplacement réel.

Avec HARD LINKS, je peux copier, tar, rsync le répertoire 'Shared Docs' et sauvegarder réellement ces documents largement dispersés en toute confiance, le contenu est en fait sauvegardé. C'est vraiment nul pour moi, quand je me suis rendu compte que je sauvegardais 0 fichier de lien et pas les informations.

L'inconvénient de l'utilisation de 'Hard Links' est que faire ls sur un répertoire ne vous donne pas une indication qu'un fichier est 'lié' à un autre fichier ou que ce fichier peut coexister. Il existe des moyens de les trouver, mais je dis que ce n'est pas évident avec un simple ls -l -> pointe vers ... Donc, j'ajoute généralement une note au début du document indiquant quel répertoire / fichiers ce fichier 'est' partagé 'avec

Landis.