* Uwe Walter wrote/schrieb:
> Zur Zeit besch�ftige ich mich mit sym- und hardlinks. Den
> einen oder anderen symlink habe ich auch schon erzeugt.
Glaub mir, Du wirst in Deinem Leben noch mehr Symlinks erzeugen, als Dir
lieb sein kann! :-))
> Was ich jetzt aber nicht verstehe, ist folgende Sache.
>
> ln -s Datei(en) Verzeichnis
>
> Werden hier mehrere Links zu einem Verzeichnis erzeugt, oder
> ein Link zu mehreren Dateien, der dann wie ein symbolisches
> Verzeichnis zu verstehen w�re?
Probieren geht �ber Studieren. Ich habs gerade probiert und wei�, was
passiert, wenn man z.B. "ln -s /home/* /tmp" macht. Keine Angst, es ist
nichts schlimmes.
> Auch sind mir einige Optionen nicht ganz klar.
Sind nicht uns allen immer mal wieder Optionen nicht klar? tar(1) oder
cpio(1) anyone? :-)
> -S (suffix) = sich �ber den �blichen Backup Suffix hinwegsetzen
>
> und
>
> -V (version control) = sich �ber die �bliche Versions-
> kontrolle hinwegsetzen
Keine Ahnung. Scheinbar hat man mit GNU-ln irgendwie die M�glichkeit eine
Historie von Dateien oder Links zu pflegen. Ich w�rde mal vermuten, da� das
mit dem Schalter "-b" in Zusammenhang steht.
> und
>
> -n (no dereference) = behandelt Links auf Verzeichnisse,
> als ob sie Dateien w�ren.
Die �bersetzung ist schlecht. In der englischen Version steht:
-n, --no-dereference
treat destination that is a symlink to a directory
as if it were a normal file
Ich denke, das macht den Sinn klarer. Es geht um das _Ziel_ der Verlinkung.
ABER:
Diese ganzen Fancy-Schalter kannst Du getrost vergessen. In der Praxis wird
ausschlie�lich mit "-s" gearbeitet. "-f" habe ich in der freien Wildbahn
noch nie gesehen und "-n" ist auf z.B. Solaris anders belegt als auf Linux.
Das BSD-ln kennt nur "-f" und "-s" als Schalter.
> Zu guter Letzt w�re da noch der Unterschied. Bei den symlinks
> wird eine Datei erzeugt. Diese habe ich mir mal angeschaut.
> Beispielsweise ist der Link auf acroread ein shell skript,
> wohingegen in der Linkdatei zu *.pdf unidentifizierbare Zeichen
> und tausende Zahlen drinstanden. Das shell skript war etwa
> 300 Zeilen lang. Der pdf-Link war ca. 89000 Zeilen lang. Damit
> konnte ich ehrlich gesagt nichts anfangen. Aber in meinen B�chern
> wird auch nur auf die symbolischen Links eingegangen. Was ist
> denn eine "echte" Verkn�pfung?
Die "Datei", die Du in "ls" siehst, kannst Du nicht anzeigen lassen. Cat,
vi usw. geben Dir immer das Ziel des Links, als w�rdest Du die verlinkte
Datei direkt ansehen. Da� der Link auf Acroread ein Shellscript ist, liegt
daran, da� Acroread ein Shellscript ist. Und was Du in den 89000 Zeilen
gesehen hast, war die PDF-Datei selbst.
Das Konzept der symbolischen Links ist mit dem LNK-Krampf von Windows nicht
vergleichbar.
> Ich habe folgendes gemacht:
>
> lern1@smurf1:~/Desktop > ln ../fh-wieb/fh-wieb_informatik.pdf \
> > fh-info
>
> Diese Verkn�pfung sieht auf den ersten Blick aus wie eine
> regul�re Datei. Wird da nur die inode der Quelldatei
> in der Dateizuordnungstabelle eingetragen?
So ist es, und so steht es auch in der Manpage. Wenn Du "ls -l" machst,
siehst Du in der zweiten Spalte, neben den Permissions eine Zahl, das ist
der Link-Count, der Dir zeigt, wieviele Directoryeintr�ge noch auf die
selbe Datei zeigen.
Wenn Du mit "rm" eine Datei l�schst, auf die noch andere Links zeigen,
l�schst Du die Links nicht mit, sondern nur diesen einen Verweis auf die
Datei. Unter Perl verwendet man z.B. "unlink()", um eine Datei zu l�schen,
das macht den Sinn klarer.
Wenn Du mit "rm" eine Datei l�schst, auf die ein symbolischer Link zeigt,
ist die Datei weg, und es bleibt ein sogenannter "Dangling Symlink" zur�ck.
Hausaufgabe: Wie kommt der Link-Count zustande, der bei Verzeichnissen
angezeigt wird? :-)
> Wenn ich nun in verschiedenen home Verzeichnissen je einen Link
> auf ein bestimmtes Verzeichnis auf dem work Laufwerk erstelle,
> heisst das dann dass alle, die in diesem Verzeichnis arbeiten,
> sich gegenseitig Schaden zuf�gen, wenn sie zur selben Zeit an
> ein und der selben Datei herumdoktern?
Naja, solange kein Blut flie�t.... ;-)
Im Zweifelsfall bleiben die �nderungen desjenigen erhalten, der als letztes
abspeichert. Wenn jeder einen anderen Symlink auf die selbe Datei
bearbeitet, bearbeiten alle die selbe Datei. Kein Unterschied, ob es ein
echter oder ein symbolischer Link ist.
Ciao,
-martin
--
COBOL programs are an exercise in Artificial Inelegance.
---------------------------------------------------------------------------
PUG - Penguin User Group Wiesbaden - http://www.pug.org