Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

MacTechNews erklärt Fachbegriffe - Dateiverknüpfungen unter OS X

Der heutige Teil der Serie "MacTechNews erklärt Fachbegriffe" beschäftigt sich mit den Dateiverknüpfungen unter OS X. Was unter früheren Systemen als Alias bekannt war, funktioniert schon lange nicht mehr so und reine UNIX-Anwendungen können auch mit klassischen Alias-Dateien nichts anfangen. Inzwischen können symbolische und harte Links gesetzt werden. Doch was bedeutet das eigentlich? Ein Leser hat sich freundlicherweise dieser Frage angenommen und ein sehr lesenswerte Erklärung geschrieben.

Weiterführende Links:

Kommentare

Fenvarien
Fenvarien31.05.04 17:30
Vielen Dank an kester für diese gute Erklärung!
Up the Villa!
0
Rantanplan
Rantanplan31.05.04 17:58
Ein Schönheitsfehler an der Erklärung:
Ändert man den Namen des harten Links, so ändert sich automatisch auch der Name des Original-Eintrags, und umgekehrt. Kein Wunder, denn beide Einträge verweisen ja auf dieselbe Datei - und die kann nicht zwei unterschiedliche Namen haben.

Das stimmt nämlich nicht. Die "Datei", also die Daten, die Eigenschaften der Datei etc. haben keinen Namen, sie haben nur eine Kennung, die node id oder kurz inode. Mit dieser Zahl ist eine Datei eindeutig im Dateisystem gekennzeichnet, nur der Mensch kommt mit Bergen von Nummer nicht gut zurecht. Daher gibt es eine zweite Struktur, das hierarchische Dateinamensystem. In diesem werden Einträge hierarchisch mit Namen aufgenommen, sie enthalten als wichtigste Zutat die inode, also die Zuordnung zu einer "echten" Datei.

Was man mit einem harten Link nun tut ist, einen zweiten Namen in diese Hierarchie einzutragen, die auf den gleichen inode verweist. Mit den Namen kann ich machen was ich will: umbenennen, löschen, verschieben (nur nicht über Volume-Grenzen hinweg). Die verschiedenen Namenseinträge zum gleichen inode sind voneinander völlig unabhängig, d.h. der Originalname - den es überhaupt nicht gibt, denn die Namenseinträge zu einem inode sind nicht priorisiert - ändert sich nicht, wenn man den Namen eines harten Links ändert. Wirklich gelöscht wird die Datei auch erst dann, wenn der letzte Verweis (Name) darauf gelöscht wird.

Wenn man sich im Terminal mit "ls -l" ein Verzeichnislisting ansieht, dann findet man in der zweiten Spalte eine Zahl. Bei Dateien ist das die Anzahl der zugehörigen "harten Links". Wer oder wo die sind, kann man vom inode allerdings nicht ableiten, nur die Anzahl wieviele harte Links es gibt.
Wenn ich nicht hier bin, bin ich auf dem Sonnendeck
0
Rantanplan
Rantanplan31.05.04 18:06
Ächz, ich sollte mich gleich mal selbst korrigieren

Der inode ist natürlich nicht die Kennung, sondern die Datenstruktur, die alle notwenigen Informationen zu einer Datei enthält (Größe, Zeitstempel, Blockliste, ...) aber - zumindest bei ufs, mit HFS+ kenne ich mich nicht so aus - nicht den Namen. Die Kennung, also die node id, ist einfach der Index in dieses Array von inodes. Und diesen Index, den findet man dann in den Dateinamen-Datensätzen wieder.
Wenn ich nicht hier bin, bin ich auf dem Sonnendeck
0
kester31.05.04 18:46
Rantanplan
Wo du gerade bei den Korrekturen bist : Mach mal 'nen Hard Link (gleicher Name - anderes Verzeichnis) und benenne den im Finder um. Verhält sich so, wie von mir beschrieben. Der Name des ersten Eintrags ändert sich auch.

Ist aber wohl ein Bug im Finder. Im Terminal steht nach wie vor der ursprüngliche Name und nach einiger Zeit springt der Name auch im Finder wieder zurück.

So lange habe ich aber nie gewartet. Danke für die Korrektur.
0
Ties-Malte
Ties-Malte31.05.04 18:59
Gut verständliche Erklärungen, danke Euch Beiden!
The early bird catches the worm, but the second mouse gets the cheese.
0
ts
ts31.05.04 19:19
Aber es gibt doch gar keine "hard links" in HFS+!?
0
kester31.05.04 19:29
ts
Laut Apple schon. Zitat: "Hard links are a feature that allows multiple directory entries to refer to a single file's content. They are a way to give a single file multiple names, possibly in multiple directories. This section describes how Mac OS X implements hard links on HFS Plus volumes."

Siehe:
0
Rantanplan
Rantanplan31.05.04 19:33
kester

Hm, bekomme ich irgendwie nicht hin. Macht aber nichts... ich habe gerade ein wenig herumgelesen, die hard links in HFS+ scheinen eine Art "Workaround" zu sein, weil es die ursprünglich dort nicht gab. HFS+ unterscheidet sich ziemlich von ufs.. uiuiui So ganz durchblicke ich das noch nicht...

Wenn ich nicht hier bin, bin ich auf dem Sonnendeck
0
Rantanplan
Rantanplan31.05.04 19:34
kester

Du warst schneller
Wenn ich nicht hier bin, bin ich auf dem Sonnendeck
0
kester31.05.04 19:51
Rantanplan
Hier mein Bug Report an Apple. Damit dürftest du es nachvollziehen können:

1) Create a hard link with the same name as the first directory entry, but in a different directory
2) Quit the terminal and open the link's directory in a Finder window.
3) Using the Finder, rename the link.
4) Using the Finder, change to the directory of the original file
5) Select the file in the Finder.
6) The file name changes to reflect the new name of the link. ERROR!
7) Open the terminal and list the directory of the original file. (It has still got it's original name)
Selcet the file in the Finder.
9) The files name changes back to it's original name. FRIGHTENING!
0
Rantanplan
Rantanplan31.05.04 20:53
Nö, irgendwie kann ich das nicht hinbekommen. Ist der Finder dabei im Symbol-, Listen- oder 3-Spaltenmodus? Eigenartig.
Wenn ich nicht hier bin, bin ich auf dem Sonnendeck
0
kester31.05.04 22:16
Im Spaltenmodus, Suffixe aus. Seltsam, ich kann das beliebig oft wiederholen.
0
lord d01.06.04 00:16
ich kanns auch nicht nachvollziehen:
10.3.3, spalten ansicht, link mit "ln" erstellt
0
Schläfer01.06.04 09:17
@kester

Moin.
Es ist gerade ein Wiki von und für Mac User im Aufbau. Dein Artikel würde da gut passen. Bei Interesse, stell ihn mit rein:



Gruss
Schläfer
0
Tice
Tice01.06.04 11:30
Gut gesprochen! Hugh!
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.