Ich stand letztens vor der Aufgabe, ein Bashscript, das ich brav in git versioniere, auf meiner Linuxmaschine in /usr/local/bin zu "installieren". Und genaugenommen hatte ich dafür drei Möglichkeiten, das Script in den jeweiligen Ordner kopieren, einen symbolischen Link oder einen harten Link erstellen. Ich dachte mir, ich schreibe mal über die Vor- und Nachteile der jeweiligen Optionen.
Kopieren
Die Variante, die so jeder kennt, der auch nur ein bisschen mit Computern zu tun hat. Die Datei einfach auf den neuen Ort zu kopieren, bringt den Vorteil, dass die Dateien voneinander unabhängig sind. Jedoch hat sie auch den Nachteil, dass sie, wie schon gesagt, voneinander unabhängig sind. Und nein, das ist nicht doppelt gemoppelt, da wir hier nicht nur einen Film abspielen, sondern etwas "installieren" möchten, und uns die ganzen Updates immer wieder daran erinnern, dass genutzte Software nie lange gleich bleibt. D. h. in unserem Beispiel, falls ein Bug auftaucht, beginnt entweder ein direktes Editieren in der installierten Datei ohne Versionierung oder ein ewiges Rumkopieren vom git Repository zum Installationspfad.
Eine Datei kopiert man z.B. unter Linux mit
cp Pfad/und/Name/der/Originaldatei Pfad/und/Name/der/Kopie
Symbolischer Link
Diese lösen ein Problem und fügen ein neues hinzu. Wir packen eine Art Verweis in den eigentlichen Ordner in unserem System, z. B. /usr/local/bin, damit das Script aufgeräumt ist, und verlinken auf unser git Repository, um Änderungen gleich zu übernehmen, sobald sie auftauchen. Nachteil Nummer eins, es kann durchaus vorkommen, dass, wenn wir bei unserem Beispiel bleiben, das git Repository gelöscht wird. Nun eiert so ein symbolischer Link in den Eingeweiden des Systems rum und führt zu nix. Nachteil Nummer zwei, was die symbolischen Links mit den harten Links gemeinsam haben, ist das Rechtemanagement. OK, solange man, wie ich, der einzige Nutzer an einem Computer ist, kann man sich das schenken, aber auf Maschinen mit nötiger Rechteverwaltung wird's schon interessanter.
Einen symbolischen Link setzt man mit
ln -s Pfad/und/Name/der/Referenzdatei Pfad/und/Name/des/symbolischen/Pfades
Harter Link
Harte Links sind schon faszinierend, wir geben einfach der Datei, die irgendwo auf der Festplatte liegt, einen zweiten Namen bzw. Verweis. Das Spannende daran ist, dass die Datei weiterhin bestehen bleibt, selbst wenn wir jetzt den "Originalnamen" löschen. Egal über welchen Weg man geht, es wird immer mit der einen Datei gearbeitet. Die Nachteile, dieser kleine Trick funktioniert meines Wissens immer nur innerhalb desselben Dateisystems. Festplattenübergreifend ist da nix zu wollen, und des Weiteren werden Rechte direkt bei der Datei gespeichert und sind vom Namen unabhängig. Für unser Beispiel würde das heißen, wenn ich die Datei im System nur von Root lesen, schreiben und ausführen lassen will, wäre diese Datei in meinem git Repository auch nur von Root behandelbar.
Einen Hardlink setzt man mit
ln Pfad/und/Name/der/Datei Pfad/und/neuer/Name/der/Datei
Nebenbei mit
stat dateiname
kann man sich anzeigen lassen, wie viele Hardlinks es auf die Datei gibt.
Interessant in dem zusammenhang sind auch
readlink -f dateiname
und
ls -la dateiname
Fazit
Das Rechteproblem ist oft ein Grund, warum beim Installieren lieber aufs Kopieren zurückgegriffen und die doppelte Versionierung damit billigend in Kauf genommen wird. Was dann meistens ein Installerscript mit sich zieht, da niemand die Zeit hat, das jedes Mal per Hand zu machen.
Andere Möglichkeiten
OK, ich war nicht ganz ehrlich, es gibt noch andere Möglichkeiten, um die gleiche Datei bzw. das gleiche Verzeichnis an zwei Orten gleichzeitig erscheinen zu lassen. Unter anderem gibt es in Windows noch Junctions und unter Linux noch bind-mount, und ich bin mir sicher, dass es noch andere Lösungen gibt, die mir gerade nicht einfallen oder die ich einfach nicht kenne. Aber für unser kleines Beispiel wäre das Overkill geworden.
In diesem Sinne,
viel Spaß
Kowo
