Des cas d'utilisation de liens physiques? [fermé]

Dans quelles situations voudrait-on utiliser un lien dur plutôt qu'un lien symbolique? Personnellement, je n'ai jamais rencontré de situation dans laquelle je souhaiterais utiliser un lien fixe au lieu d'un lien symbolique, et le seul cas d'utilisation rencontré lors de la recherche sur le Web est la déduplication de fichiers identiques .

Outre l'utilisation de la sauvegarde mentionnée dans un autre commentaire, qui inclut, je crois, les instantanés sur un volume BTRFS, un scénario d'utilisation pour les liens physiques via des liens logiciels est une collection de fichiers triés par balises. (Ce n'est pas forcément la meilleure méthode pour créer une collection, une méthode basée sur une base de données est potentiellement meilleure, mais pour une collection simple qui est raisonnablement stable, ce n'est pas si mal.)

Une collection de médias dans laquelle tous les fichiers sont stockés dans un, un plat, un répertoire et sont classés dans d'autres répertoires en fonction de divers critères, tels que: année, sujet, artiste, genre, etc. Il peut s'agir d'une collection de films personnelle ou du collectif d'un studio commercial travaux. Essentiellement terminé, le fichier est enregistré, peu susceptible d’être modifié, et trié, éventuellement en plusieurs emplacements par liens.

N'oubliez pas que les concepts "original" et "copie" ne s'appliquent pas aux liens physiques: chaque lien vers le fichier est un original, il n'y a pas de "copie" au sens habituel. Pour la description du cas d'utilisation, toutefois, les termes imitent la logique du comportement.

"L'original" est enregistré dans le répertoire "catalogue" et les "copies" triées sont liées à ces fichiers. Les attributs de fichier sur les répertoires de tri peuvent être définis sur r / o, ce qui empêche toute modification accidentelle des noms de fichiers et de la structure triée, tandis que les attributs du répertoire de catalogue peuvent être r / w, ce qui permet de le modifier selon les besoins. (Par exemple, certains lecteurs essaient de renommer et de réorganiser des fichiers en fonction de balises incorporées dans le fichier multimédia, à partir de la saisie de l'utilisateur ou de la recherche sur Internet.) De plus, les attributs des répertoires "copy" pouvant être différents de le répertoire "original", la structure triée pourrait être mise à la disposition du groupe, ou du monde, avec un accès restreint, tandis que le "catalogue" principal est uniquement accessible à l'utilisateur principal, avec un accès complet. Les fichiers eux-mêmes, cependant, auront toujours les mêmes attributs sur tous les liens vers cet inode. (Les ACL pourraient être explorées pour améliorer cela, mais pas mon domaine de connaissances.)

Si l'original est renommé ou déplacé (le répertoire "catalogue" devient trop volumineux pour être géré, par exemple), les liens fixes restent valides, les liens symboliques étant rompus. Si les "copies" sont déplacées et que les liens symboliques sont relatifs, les liens symboliques seront, à nouveau, rompus et les liens physiques ne le seront pas.

Remarque: il semble exister une incohérence dans la façon dont différents outils signalent l'utilisation du disque lorsque des liens symboliques sont impliqués. Avec les liens durs, cependant, cela semble cohérent. Donc, avec 100 fichiers dans un catalogue triés dans une collection de "tags", il pourrait facilement y avoir 500 "copies" liées. (Pour une collection de photographies, par exemple la date, le photographe et une moyenne de 3 balises "subject".) Dolphin, par exemple, indiquerait cela comme 100 fichiers pour les liens fixes et 600 fichiers si des liens symboliques sont utilisés. Fait intéressant, il indique la même utilisation de l’espace disque, de sorte qu’il ressemble à une vaste collection de petits fichiers pour les liens symboliques et à une petite collection de gros fichiers pour les liens physiques.

Un inconvénient à ce type de cas d'utilisation est que, dans les systèmes de fichiers qui utilisent COW, la modification de "l'original" peut rompre les liens fixes, mais pas les liens souples. Mais si l'intention est de conserver la copie originale, après l'avoir modifiée, sauvegardée et triée, COW n'entre pas dans le scénario.

Les liens physiques sont utiles dans les cas où vous ne souhaitez pas lier l'existence des deux fichiers. Considère ceci:

touch a
ln -s a b
rm a

Maintenant best inutile. (Et ces étapes peuvent se dérouler assez loin l'une de l'autre, être effectuées par différentes personnes, etc.)

Alors qu'avec un lien dur,

touch a
ln a b
rm a

b est toujours présent et correct.

Un programme unique peut changer de comportement en fonction du nom sous lequel il est lancé:

$ ls -li `which pgrep` `which pkill`
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pgrep
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pkill

Qui dans la source est décidé via quelque chose comme

if (strcmp(__progname, "pgrep") == 0) {
    action = grepact;
    pgrep = 1;
} else {
    action = killact;

bien que les détails exacts varient en fonction du système d'exploitation et de la langue utilisée.

Cela permet (la plupart du temps) de ne pas avoir à compiler du code identique en deux binaires (la plupart du temps) identiques. Gardez à l'esprit les dates unix à l'époque où l'espace disque était extrêmement coûteux, même si selon Stevens du chapitre 4 de l'APUE, des liens symboliques ont été mis en place dans BSD4.2 (1983) pour remplacer diverses limitations des liens durs. Un programme de test pour vérifier si le nom du lien symbolique est utilisé, car le nom du programme pourrait ressembler à ceci:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
    printf("called as '%s'\n", *argv);
    exit(0);
}

Et testé via:

$ cc -o myname myname.c 
$ ln -s myname alias
$ ./myname
called as './myname'
$ ./alias
called as './alias'
$ 

Lorsque mon logiciel P2P a fini de télécharger un certain fichier, celui-ci est placé dans un répertoire spécifique. Les fichiers téléchargés n’ont pratiquement jamais besoin d’être édités. Le cas le plus courant est que je crée un lien physique dans un répertoire différent où j'ai besoin du fichier.

Avantages:

• Je partage toujours le fichier dans le réseau P2P comme je le devrais, même si je rmoumv la "copie".
• Le fichier est également sur le chemin où j'en ai besoin; la plupart de ces endroits ne sont pas partagés.
• je peux rm le "original" pour arrêter de partager le fichier; cette opération n'affecte pas la "copie" à l'endroit désiré.
• Mon espace disque est utilisé une seule fois.

Le point principal: si je savais d'avance quel fichier je voudrais d' rmabord, je pourrais utiliser un lien symbolique. Mais je ne sais jamais.

Les systèmes de fichiers constituent un moyen simple, mais efficace, d’organiser et de classer les fichiers (c’est leur raison d’être primordiale). Les liens durs permettent une plus grande flexibilité dans ce domaine.

Comme mentionné, il n'y a pas de concept d'original et de copies lorsqu'il s'agit de liens durs, toutes les entrées de répertoire (liens durs) sont simplement des références à l'existence du fichier (point sur son inode) sans précédent, il n'y a donc pas non plus de lien dur rompu. .

Donc là , il y a quelques - uns des cas d'utilisation qui les liens physiques fréquentent , mais les liens logiciels ne le font pas :

1. Imaginez que vous ayez une collection de films, de musique ou d’autres supports et que vous souhaitiez appliquer différents critères de classification, comme des chansons classées par artiste dans une branche (chaque artiste a son propre sous-répertoire); par genre dans une autre branche (chacun dans un sous-répertoire différent), etc. Cependant, vous ne voulez pas dupliquer les fichiers, ni décider où placer l'original, pour avoir la liberté de reclassifier sans avoir à le faire. gérer "et relier les fichiers lors du déplacement afin d'éviter les liens brisés.

2. Une autre raison est d’éviter le gaspillage d’espace de stockage qui serait nécessaire pour avoir plusieurs copies du même fichier tout en permettant au chrootsystème de bénéficier d’un sous-ensemble de fichiers dans la racine du système de fichiers "maître" (les liens symboliques ne pourraient jamais référencer des fichiers de l’extérieur). le chrootbac à sable, même s’ils ont des chemins relatifs).

3. Les ..sous - répertoires sont une autre raison très importante mais rarement mentionnée . Les ..répertoires sont en fait (dans la plupart des implémentations unix) des liens durs vers le répertoire parent. Sans liens durs, cela doit être implémenté d’une manière complètement différente, alors que l’existence de liens durs le rend très facile à implémenter.

Très commun, exemple du monde réel qui nécessite des liens durs:

git clone --reference <repository>

Cela clone à partir d'un dépôt Git local avec une copie presque nulle. Au lieu de copier les fichiers objets (fichiers immuables utilisés par Git pour sa "base de données"), il les lie simplement.

Tout repo peut supprimer un objet, mais l'inode reste valable pour le reste du repo. Et si un objet est supprimé de tous les dépôts, il est supprimé du disque. Les liens durs constituent une solution extrêmement robuste et rapide. Très commun dans les serveurs CI.

Il existe une version non-hard-link: git clone --shared <repository>. Cependant, ceci est instable et comporte de nombreuses autres mises en garde puisque tout le monde travaille sur le même répertoire.

J'ai récemment eu un cas d'utilisation pour une procédure de mise à jour assez sûre pour les systèmes U-Boot où uImageun lien symbolique pointant vers l'image à démarrer, l'idée était qu'une panne de courant ne devrait poser aucun problème, peu importe à quel moment de la mise à jour. le processus se produit (en supposant que le système de fichiers fonctionne bien):

ln image.bin backup_image.bin
ln -sf backup_image.bin uImage

// replace image.bin

ln -sf image.bin uImage
rm backup_image.bin

Sans liens durs, cela ne serait pas si simple.

/modifier:

Grâce aux commentaires, je sais maintenant qu'il serait préférable de faire:

ln image.bin backup_image.bin
ln -sf backup_image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage

// replace image.bin

ln -sf image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage
rm backup_image.bin

(Le rmest ici pour pouvoir mieux sortir d'un état étrange, par exemple s'il uImages'agit d'un imprévu qui ferait mvéchouer [mais pas nécessairement la ln -sfsolution précédente ].)

Une utilisation que j'ai eu pour les liens durs est lors du téléchargement ou de la décompression d'un fichier endommagé. Le programme qui télécharge ou décompresse (par exemple, unzip ou unrar) supprime souvent automatiquement le fichier incomplet lorsqu'il rencontre une erreur, et il n’ya généralement pas d’option pour le conserver. Si je veux conserver le fichier, je peux établir un lien solide avec celui-ci.

BackupPC est un système de sauvegarde qui utilise des liens physiques sur les serveurs pour fournir une déduplication au niveau des fichiers.

Les fichiers sont d'abord stockés dans une arborescence de répertoires "pool" en fonction de leur hachage md5. Toute sauvegarde utilisant ce fichier crée un lien matériel avec le fichier de pool. Lorsque les sauvegardes expirent / sont supprimées, leurs liens physiques sont supprimés du système de fichiers.

Les liens physiques sont supérieurs aux liens symboliques ici car ils fournissent un comptage automatique des références. Un travail cron supprime périodiquement les fichiers du répertoire du pool ne comportant pas plus d'un lien.

Cette méthode présente certains inconvénients (principalement le fait qu’il est difficile d’utiliser des outils basés sur un système de fichiers pour répliquer le magasin de sauvegarde), mais elle s’est avérée assez robuste en pratique.

Autre cas d’utilisation: le serveur d’applications Web tomcat java traite les noms de fichiers comme des métadonnées. Un fichier java "war" doit être nommé en fonction de son chemin d'accès sur le serveur Web.

par exemple: foo.war est le code Java qui sert l'URL/foo

Malheureusement, il résout les liens symboliques avant de prendre cette décision.

Supposons donc que vous souhaitiez déployer une version d’application et lui attribuer un nom de fichier descriptif (avec, par exemple, un numéro de version ou une date). Vous ne pouvez pas créer de lien symbolique vers le fichier avec le nom "réel" - vous devez créer un lien dur.

foo.warlien symbolique vers foo-20170129.warne fonctionne pas

foo.warrelié durement aux foo-20170129.warœuvres.

Je n'aime pas ce comportement de tomcat, mais les liens physiques me permettent de le contourner.