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.