Hardlinks funktionieren gar nicht

[maceis]

Hallo zusammen,

ich musste gerade feststellen, dass Hardlinks bei mir unter Mac OS X 10.4.9 gar nicht funktionieren.

Ich habe eine Datei, die aus zwei Verzeichnisseinträgen heraus aufgerufen werden muss. Also dachte ich mir, ich erstelle einen Hardlink wie folgt:

ln ../070319/test.txt test.txt
ls -l test.txt
-rw-r--r-- [b]2[/b] maceis maceis .... test.txt

Problem ist nur, dass sich die mit dem ln Befehl erzeugte Datei wie eine Kopie verhält. Änderungen auf der einen Seite, werden auf der anderen ignoriert.
Steh ich jetzt ganz auf der Leitung? Mach' ich was falsch?
Kann das mal jemand bei sich überprüfen?

 

[Darii]

Die 2 bei ls zeigt ja an, dass da ein Link besteht. Sicher, dass alle Pfade etc stimmen?

$ echo "blub" > dat1
$ ln dat1 dat2
$ echo "blub2" > dat1
$ cat dat2
blub2
$ ls -l
total 16
-rw-r--r--   2 test  test  6 Mar 19 19:55 dat1
-rw-r--r--   2 test  test  6 Mar 19 19:55 dat2

 

[MacMännchen]

Problem ist nur, dass sich die mit dem ln Befehl erzeugte Datei wie eine Kopie verhält. Änderungen auf der einen Seite, werden auf der anderen ignoriert.

kann ich bestätigen. Das ist ein Widerspruch zur "2", die bei ls angezeigt wird.

 

[MacMännchen]

Hab's heute noch mal unter Linux probiert. Dort verhält es sich genau so. Also kein Widerspruch.

Ich muss dazusagen, ich arbeite, wenn mit "ln", dann nur mit Softlinks. Daher hatte mich dieses Verhalten bei Hardlinks etwas "überrascht".

 

[maceis]

Hab jetzt wenigstens eine teilweise Erklärung für meine Misserfolge.

Ich hatte testweise kleine Textdateien erstellt und davon einen Hardlink in einem anderen Verzeichnis erstellt (Softlinks sind für meine Zwecke nicht geeignet).
Nun habe ich bemeerkt, dass die Hardlinks erwartungsgemäß funktionieren, wenn ich die Dateien mit vim editiere und bearbeite.

Wenn ich eine solche Textdatei aber mit Textedit ändere und sichere, erstellt Textedit beim Sichern eine neue Datei und überschreibt damit die alte. Der Link ist damit unterbrochen.
Das ist natürlich ein Riesenkäse Apple!

Außerdem habe ich noch ein anderes sehr seltsames Verhalten bemerkt.
Wenn ich CAD Dateien, mit zwei Linkeinträgen bearbeite, führen Änderung unter dem einen Eintrag zunächst nich zu einer Aktualisierung der Änderungszeit bei dem anderen Eintrag. Erst wenn ich das 'ln' Kommando (mit dem Schalter -f) erneut ausführe, werden die Änderungszeiten aktualisiert.

Auch das ist ein Riesenkäse!
Ich erwarte, wenn ich eine Datei unter dem einen Namen ändere, dass sich auch bei dem anderen Namen die Änderungszeit ändert. Ist doch schließlich die selbe Datei, oder?

Edit:
Grade nochmal getestet; mit vi funktioniert das auch. Nur mit dem CAD Programm wird die Änderung eines Linkeintrages erst bei neu erstellen der Links auch beim anderen Zweig übernommen. Sehr eigenartig!

 

[Darii]

Das mit Textedit ist in der Tat seltsam, imho ein Riesenbug. Ist vermutlich noch keinem aufgefallen, da keine gehardlinkte Dateien mit Textedit bearbeitet. Scheint aber irgendwie ein generelles Problem mit den entsprechenden cocoa-Funktionen zu sein. SubEtha zickt auch rum und verlangt Administratorrechte

 

[MacMännchen]

Von einem Bug kann man eigentlich nicht sprechen. Es ist auch kein Plattform-spezifisches Problem, sondern einfach davon abhängig, ob der Texteditor nach Änderungen in die Originaldatei schreibt oder in eine Kopie, bzw. das Original umbenennt.

Habe es heute noch mal unter OS X, suse und debian ausprobiert.
Hardlinks funktionieren bei vi und vim, aber nicht mit emacs oder dem Textedit auf dem Mac.

 

[maceis]

Was? emacs mach auch so einen Krampf?
Ein Glück, dass ich mit vim arbeite .

Ob man es jetzt als ausgesprochenen Bug bezeichnen möchte, sei jetzt einmal dahin gestellt.
Ich finde es aber ausgesprochen schlecht, weil auf diese Art Strukturen zerstört werden - wenn ich's mir recht überlege: Doch, das sind Bugs!
Werd' ich wohl auch mal bei Apple melden - mal seh'n was draus wird.

 

[dpr]

Was? emacs mach auch so einen Krampf?

Das kommt drauf an: Carbon Emacs 22.0.95 (auch: .50) und emacs 21.2.1 verhalten sich korrekt.

 

[MacMännchen]

Wenn ich ein Datei hard verlinke und dann mit GNU Emacs 21.2.1 (powerpc-apple-darwin8.0) das Original verändere, wird die hard verlinkte Datei nicht mit verändert. Im Unterschied zu vim.

 

[dpr]

Wenn ich ein Datei hard verlinke und dann mit GNU Emacs 21.2.1 (powerpc-apple-darwin8.0) das Original verändere, wird die hard verlinkte Datei nicht mit verändert.

Dann ist Dein emacs kaputt, denn hier funktioniert das, wie es soll. Wo hast Du den denn her?

Beispiel:

host:/tmp% touch test
host:/tmp% ln test test2
host:/tmp% ll -i test*
1240601 -rw-r--r--   2 dpr  wheel  0 Mar 27 20:54 test
1240601 -rw-r--r--   2 dpr  wheel  0 Mar 27 20:54 test2
host:/tmp% emacs test
host:/tmp% ll -i test*
1240601 -rw-r--r--   2 dpr  wheel  4 Mar 27 20:54 test
1240601 -rw-r--r--   2 dpr  wheel  4 Mar 27 20:54 test2

 

[maceis]

Wenn ich ein Datei hard verlinke und dann mit GNU Emacs 21.2.1 (powerpc-apple-darwin8.0) das Original verändere, wird die hard verlinkte Datei nicht mit verändert. Im Unterschied zu vim.

Ich glaube, da ist ein logischer Fehler in Deinem Satz.
Du sprichst von einem "Original" und einer "hard verlinkten Datei".
Tatsächlich gibt es aber nur eine Datei.

Das sonderbarste Verhalten finde ich derzeit unter ArchICAD:
Ich habe 11 Dateien, die in zwei Ordner jeweils einen Verzeichniseintrag haben. Alle 11 Dateien sind unter einem der beiden Verzeichnispfade in einer Masterdatei verlinkt.

Nun ändere ich drei Dateien, unter dem anderen Verzeichnispfad.
Wenn ich die Masterdatei nun aktualisiere, "merkt" sie nicht, dass sich die drei Dateien geändert haben und läd keine nach.
Wenn ich aber nun die Links für alle 11 Dateien neu erstelle und dann aktualisiere, läd die Masterdatei genau die drei geänderten Dateien nach, nicht aber die anderen, die ebenfalls neu erstellt wurden.

Tut mir Leid, aber das versteh' ich einfach nicht!

 

[MacMännchen]

Dann ist Dein emacs kaputt, denn hier funktioniert das, wie es soll. Wo hast Du den denn her?

Die emacs Version ist von meiner Tiger DVD.

 

[MacMännchen]

Ich glaube, da ist ein logischer Fehler in Deinem Satz.
Du sprichst von einem "Original" und einer "hard verlinkten Datei".
Tatsächlich gibt es aber nur eine Datei.

Ist schon klar, dass es nur eine Datei gibt. Sorry, dann hatte ich mich missverständlich ausgerückt.

Wenn ich eine Datei, auf die ein Hardlink gesetzt ist, mit vim verändere, dann kann ich mir hinterher das Ergebnis sowohl über die Originaldatei ansehen, als auch über den Hardlink (z.B. mit cat oder less).
Das funktioniert mit emacs eben nicht. Der Link wird zwar über die "2" bei ls angezeigt, aber es verhält sich so, als ob er gebrochen wäre.

 

[dpr]

Die emacs Version ist von meiner Tiger DVD.

Bei mir ebenfalls.

Neuer Versuch, man achte auf die (im Vergleich zu obigem Beispiel) unterschiedliche GID:

host:/Volumes/test% touch test
host:/Volumes/test% ln test test2
host:/Volumes/test% ll -i test*
26 -rw-r--r--   2 dpr  users  0 Mar 28 21:45 test
26 -rw-r--r--   2 dpr  users  0 Mar 28 21:45 test2
host:/Volumes/test% emacs test
host:/Volumes/test% ll -i test*
30 -rw-r--r--   1 dpr  users  4 Mar 28 21:45 test
26 -rw-r--r--   2 dpr  users  0 Mar 28 21:45 test2
26 -rw-r--r--   2 dpr  users  0 Mar 28 21:45 test~

 

[MacMännchen]

Um das oben gesagte zu verdeutlichen, hier noch mal der Unterschied nach dem Verändern einer Datei.

Bei vi sieht's so aus:

mini:~/test mm$ touch test
mini:~/test mm$ ln test test2
mini:~/test mm$ ls -l test*
-rw-r--r--   2 mm  mm  0 Mar 30 09:51 test
-rw-r--r--   2 mm  mm  0 Mar 30 09:51 test2
mini:~/test mm$ vi test
mini:~/test mm$ ls -l test*
-rw-r--r--   2 mm  mm  12 Mar 30 09:52 test
-rw-r--r--   2 mm  mm  12 Mar 30 09:52 test2
mini:~/test mm$ cat test
neue Zeile

mini:~/test mm$ cat test2
neue Zeile

emacs verhält sich anders:

mini:~/test mm$ touch test
mini:~/test mm$ ln test test2
mini:~/test mm$ ls -l test*
-rw-r--r--   2 mm  mm  0 Mar 30 09:53 test
-rw-r--r--   2 mm  mm  0 Mar 30 09:53 test2
mini:~/test mm$ emacs test
mini:~/test mm$ ls -l test*
-rw-r--r--   1 mm  mm  11 Mar 30 09:53 test
-rw-r--r--   2 mm  mm   0 Mar 30 09:53 test2
-rw-r--r--   2 mm  mm   0 Mar 30 09:53 test~
mini:~/test mm$ cat test
neue Zeile
mini:~/test mm$ cat test2
mini:~/test mm$ cat test~
mini:~/test mm$

 

[dpr]

Um das oben gesagte zu verdeutlichen

Was Du bei Deiner Zusammenfassung leider entfernt hast: Die Inode (ls -i) ist der spannende Teil. Außerdem sind die Rechte des aktuellen Verzeichnisses von Bedeutung[1], denn in Abhängigkeit davon erzeugt Emacs entweder eine Kopie (das Original verbleibt als *~) oder schreibt auf das Original. Das kann man jetzt natürlich anhand der Quellen prüfen, allerdings fehlt mir dazu jetzt der Ehrgeiz.

[1] Man beachte dazu die GID einer in einem durch die Welt schreibbarem Verzeichnis erzeugten Datei. Hier gibt es Unterschiede zwischen einem BSD und etwa Linux.

 

[MacMännchen]

Was Du bei Deiner Zusammenfassung leider entfernt hast: Die Inode (ls -i) ist der spannende Teil.

Na ja, ist Ansichtssache.
Das spannendste war für mich der Endeffekt, nämlich der unterschiedliche Inhalt der angezeigten Dateien. Die Inodes sind eigentlich nicht mehr so prickelnd, bestätigen sie doch genau das schon gepostete Ergebnis (siehe auch unterschiedliche Dateilängen).

Aber bitte, hier noch mal eine gekürzte Fassung mit Inodes:

mini:~/test mm$ touch test
mini:~/test mm$ ln test test2
mini:~/test mm$ ls -i
total 0
1384290 -rw-r--r--   2 mm  mm  0 Mar 30 18:40 test
1384290 -rw-r--r--   2 mm  mm  0 Mar 30 18:40 test2
mini:~/test mm$ vi test
mini:~/test mm$ ls -i
total 16
1384290 -rw-r--r--   2 mm  mm  12 Mar 30 18:40 test
1384290 -rw-r--r--   2 mm  mm  12 Mar 30 18:40 test2
mini:~/test mm$ emacs test
mini:~/test mm$ ls -i
total 24
1384299 -rw-r--r--   1 mm  mm  22 Mar 30 18:42 test
1384290 -rw-r--r--   2 mm  mm  12 Mar 30 18:40 test2
1384290 -rw-r--r--   2 mm  mm  12 Mar 30 18:40 test~

 

[dpr]

Die Inodes sind eigentlich nicht mehr so prickelnd [...] Aber bitte, hier noch mal eine gekürzte Fassung mit Inodes

Es ging mir weniger darum, hier noch ein Listing zu sehen, denn das Symptom ist klar; sondern darum, darauf hinzuweisen, daß die Inodes _und_ Permissions des Verzeichnisses in diesem Fall sehr wohl relevant sind. Ansichtssache ist unbestritten, ob und wie genau man Ursachenforschung betreibt. Anyway, was Ergebnis paßt unter bestimmten Umständen nicht.

BTW: Hast Du den emacs-Patch schon fertig? ;-)

Sorry an den OP, der Thread ist nun wohl doch etwas vom eigentlichen Thema abgedriftet...

 

[MacMännchen]

BTW: Hast Du den emacs-Patch schon fertig? ;-)

ja, hab' ich inzwischen.

Aber du hast Recht, dem eigentlichen Problem des Threaderstellers hilft das nicht weiter.