Wann wäre es sinnvoll, einen festen Link zu erstellen?

Grundsätzlich gibt es bei Hardlinks zwei Hauptbeschränkungen:

1. Für Hardlinks müssen sich der Link und die Datei normalerweise im selben Dateisystem befinden.
2. Nur der Superuser kann einen festen Link zu einem Verzeichnis erstellen.

Daher wurden symbolische Links eingeführt, um die Einschränkungen von Hardlinks zu umgehen. Die Frage ist also, ob noch harte Links benötigt werden. Könnte es eine Situation geben, in der sie nützlicher sind?

Hardlinks helfen uns dabei, unser Dateisystem viel flexibler zu organisieren. Grundsätzlich ermöglichen uns Hardlinks, eine Datei zu nehmen und mehrere Stellen gleichzeitig im Dateisystem zu haben. Denken Sie an ein Szenario, in dem Sie Fotograf sind und viele Fotos haben (dies ist ein Beispiel aus meinem Leben!). Sie können sie nach den Personen organisieren, die in ihnen erscheinen, da Sie manchmal nach Fotos von ihnen gefragt werden. Möglicherweise möchten Sie sie aber auch nach Ort und Datum organisieren. Es gibt keine wirkliche Möglichkeit, diese drei Dinge zu verschachteln, sie sind völlig getrennte Organisationsachsen. Sie können also drei verschiedene Hierarchien für diese drei verschiedenen Dinge erstellen und jedes Foto in allen drei ohne vorhanden habenjedes Foto dreimal speichern müssen. Das ist die Magie von Hardlinks. Wenn Sie die Verknüpfung von Symlinks aufheben, müssen wir uns keine Gedanken darüber machen, wo sich die "echte Datei" befindet, da es sich bei allen um die echte Datei handelt. Wir können nach Belieben löschen und verschieben, da die Datei so lange beibehalten wird, bis keine Verweise mehr darauf vorhanden sind, und beim Löschen des letzten Hardlinks entfernt wird. Es ist einfach und erfordert nicht, dass Sie sehr viel im Auge behalten.

Der Inhalt einer Datei wird erst gelöscht, wenn alle Hardlinks (ja, alle Dateinamen sind Hardlinks, auch die ersten) gelöscht und die Datei geschlossen wurden. Als solches kann es nützlich sein, wenn eine Datei an mehreren Stellen benötigt wird, aber jederzeit aus einer von ihnen entfernt werden kann, z . B. zwischen ~/Downloads/coolsong.mp3und ~/Music/Cool Song.mp3.

Ein nicht sehr wichtiger Vorteil eines Hardlinks gegenüber einem symbolischen Link besteht darin, dass der Kernel beim Erreichen des Inodes für einen Hardlink keine weitere Verarbeitung für den Zugriff auf die Datei durchführen muss. Wenn eine symbolische Verknüpfung auftritt, muss der Kernel den Verknüpfungswert lesen und die Verzeichnisstruktur weiter durchlaufen, bevor er zum Inode für die Datei gelangt. Dies dauert länger, obwohl der Unterschied nicht unbedingt leicht zu messen ist. Es macht wirklich Spaß, wenn eines der Elemente des Symlink-Werts selbst ein Symlink ist.

Es gibt mehrere Gründe für Hardlinks

1. Verweise auf eine Datei zu behalten, bis die letzte Referenz verschwunden ist (wie Ignacio betonte)
2. Wenn Sie Dateien fest verknüpfen, belegen sie nur den Speicherplatz einer Datei im Dateisystem (beide Verweise auf die Datei haben dieselben i-Knoten). Daher müssen sich Hardlinks im selben Dateisystem befinden.

Ein Grund für die Verwendung von Hardlinks ist also, möglicherweise viel Platz zu sparen ...

Sie können an eine der Referenzen anhängen, und die Daten werden in die freigegebene Datei übernommen. Sie können auch an einen Dateideskriptor anhängen, während Sie aus dem anderen lesen (z. B. mit tail -f).

Viele der hier angegebenen Beispiele sind gültig, funktionieren jedoch genauso gut mit Softlinks (z. B. das Problem "Eine Datei an mehreren Stellen benötigen").

Ein gutes Beispiel dafür, wo Hardlinks wirklich hilfreich sind, ist die Backup-Software Dirvish :

Dirvish ist ein schnelles, festplattenbasiertes, rotierendes Netzwerksicherungssystem.

Mit dirvish können Sie eine Reihe vollständiger Images Ihrer Dateisysteme mit unbeaufsichtigter Erstellung und Ablauf verwalten. Ein Dirvish-Backup-Tresor ist wie eine Zeitmaschine für Ihre Daten.

Dirvish erstellt Sicherungen auf Dateisystemebene (dh es kopiert Dateien, es werden keine Bilder erstellt), indem Dateien auf ein separates (Sicherungs-) Dateisystem (z. B. eine USB-Festplatte) kopiert werden. Jedes Mal, wenn Sie ein Backup erstellen, erstellt dirvish eine separate, vollständige Kopie des zu speichernden Verzeichnisbaums.

Der Trick besteht darin, dass wenn dirvish feststellt, dass bereits eine ältere Sicherungskopie des von Ihnen gespeicherten Baums vorhanden ist, Dateien, die nicht geändert wurden, automatisch wiederverwendet werden, indem im neuen Baum ein fester Link zur Datei im alten Baum erstellt wird.

Auf diese Weise ist jede Sicherungskopie eine vollständige, in sich geschlossene Kopie des Verzeichnisbaums, gleichzeitig nehmen jedoch nur die geänderten Dateien tatsächlich Speicherplatz im Dateisystem ein. Mit anderen Worten, Sie profitieren gleichzeitig von inkrementellen Sicherungen (Platzersparnis) und vollständigen Sicherungen (einfaches Abrufen).

Dies ist nur möglich, weil Hardlinks für Userspace-Tools vollständig transparent sind.

Dies würde wahrscheinlich auch mit symbolischen Links funktionieren (obwohl beim Sichern von Daten, die symbolische Links selbst verwenden, Probleme auftreten würden), aber ein Vorteil, der nur mit harten Links möglich ist, ist:

Wenn Sie alte Backups wegwerfen möchten, können Sie einfach den entsprechenden Backup-Verzeichnisbaum löschen. Dateien, die nur mit diesem Baum verknüpft sind, werden vom Dateisystem automatisch gelöscht (da der letzte feste Link gelöscht wird). Dateien, die auch in anderen Kopien enthalten sind, verbleiben jedoch auf der Festplatte.

Ein nützlicher Fall ist beispielsweise, wenn Sie ein Programm (oder Skript) haben, das einen großen temporären Tarball herunterladen muss, und Ihr Programm ihn nach dem Extrahieren sofort löscht.

Wenn Sie diesen Tarball aus irgendeinem Grund für die zukünftige Verwendung aufbewahren möchten, ist dies am besten möglich, ln /tmp/tarball.tgz ~solange der Tarball noch heruntergeladen wird. Dann brauchen Sie nichts zu tun.

Wenn der Download abgeschlossen ist und auch nachdem Ihr Programm das "Original" gelöscht hat, sollte sich die genaue Kopie noch in Ihrem Home-Verzeichnis befinden.

Ich verwende 'Hard Links', um einige meiner 'HowTos' und Snippets zu sichern

Ich habe ein Verzeichnis mit dem Namen "Shared Docs" in meinem Benutzer / Stammverzeichnis. In diesem Verzeichnis habe ich "harte Links" zu meinen Tipps, Tricks, Schnipsel und Anleitungen, die in den entsprechenden Verzeichnissen gespeichert sind. PHP, MySQL, CSS, Regex, Formeln, Linux usw. Wenn Sie sie an einem Ort haben, ist es viel einfacher, sie zu verwenden und zu aktualisieren, als in meinen Dokumenten / Verzeichnissen nach diesen Dokumenten suchen zu müssen, die ich häufig verwende.

Vor langer Zeit habe ich Symlinks verwendet. Ich würde dieses gemeinsame Verzeichnis "Shared Docs" getreu auf meinem Server sichern. Das Problem ist, dass Symlinks oder 'Soft Links', wenn sie kopiert (cp -auv) oder tariert und kopiert werden, NUR den 'Link' und NICHT den Inhalt des Dokuments sichern oder kopieren. Also müsste ich die Verzeichnisse durchlaufen und jede von 2 Dutzend Dateien von ihrem tatsächlichen Speicherort kopieren.

Mit HARD LINKS kann ich das Verzeichnis 'Shared Docs' kopieren, tarieren, synchronisieren und diese weit verbreiteten Dokumente mit Sicherheit sichern. Der Inhalt wird tatsächlich gesichert. Es ist wirklich scheiße für mich, als ich merkte, dass ich 0 Biss-Link-Dateien und nicht die Informationen gesichert hatte.

Der Nachteil bei der Verwendung von 'Hard Links' ist, dass das Ausführen von ls in einem Verzeichnis keinen Hinweis darauf gibt, dass eine Datei mit einer anderen Datei 'verknüpft' ist oder wo diese Datei möglicherweise nebeneinander existiert. Es gibt Möglichkeiten, sie zu finden, aber ich sage, es ist nicht offensichtlich, wenn ein einfaches ls -l -> auf ... verweist. Daher füge ich normalerweise am Anfang des Dokuments eine Notiz hinzu, die angibt, in welchem ​​Verzeichnis / in welchen Dateien sich diese Datei befindet 'wird' geteilt 'mit

Landis.