Hardlinks funktionieren gar nicht

[Quizzler]

Hmm ... Kann ich auch ganze Ordner Strukturen auf ein mal hart Verlinken?

Ich will, dass z.B.

Quizzler/step0/step1 und Quizzler/stepX
Auf die selbe Ordnerstruktur zurückgreifen.

 

[below]

Hmm ... Kann ich auch ganze Ordner Strukturen auf ein mal hart Verlinken?

Ich will, dass z.B.

Quizzler/step0/step1 und Quizzler/stepX
Auf die selbe Ordnerstruktur zurückgreifen.

Natürlich. Die meinsten Menschen wollen aber keine harten Links, sondern lieber Symlinks

Alex

 

[magheinz]

benutzt mal die suchfunktion.
wir hatten schon mal eine ähnliche diskussion.
einige apple-programme sind nicht in der lage eine datei zu öffnen, zu editieren und zu speichern. sie legen IMMER eine kopie an. das zerstört dann natürlich links.

das problem betrifft nicht alle programme, textedit war aber eines davon.

meiner meinung nach ist das ein schwerwiegender bug der jeweiligen anwendungen oder zumindest der verwendeten bibliothek da sie definitiv etwas anderes machen als sie dem user suggerieren. sprich, das verhalten ist anders als erwartet und dokumentiert.

in verbindung mit z.b. timemachine könnte sich der bug richtig negativ auswirken. unter anderem durch größeren platzbedarf bei den backups.

 

[below]

meiner meinung nach ist das ein schwerwiegender bug der jeweiligen anwendungen oder zumindest der verwendeten bibliothek da sie definitiv etwas anderes machen als sie dem user suggerieren. sprich, das verhalten ist anders als erwartet und dokumentiert.

Nein, das Verhalten ist genau wie dokumentiert. Jedenfalls für den Entwickler.

Hier geht es um eine bestimmte Art der Sicherheit: Die alte Datei wird erst dann gelöscht, wenn die neue erfolgreich geschrieben wurde.
Würde man die alte Datei direkt modifizieren, würde man bei einem Fehler beide Versionen, die alte und die neue, verlieren.

Natürlich, es ist ein Trade-Off. Aber das muss einem bei der Verwendung von Hardlinks klar sein. Die legt man ja schliesslich nicht im Finder an.

Alex

 

[magheinz]

Nein, das Verhalten ist genau wie dokumentiert. Jedenfalls für den Entwickler.

Dann sollte man es dem Anwender deutlich machen.
Wenn ich auf [Datei speichern] klicke erwarte ich das die Datei gespeichert wird und nicht das eine Kopie angelegt wird.
Mich würde es jetzt mal brennend interessieren WO dieses Verhalten für Entwickler dokumentiert ist.
Haste da mal nen link zu?

Hier geht es um eine bestimmte Art der Sicherheit: Die alte Datei wird erst dann gelöscht, wenn die neue erfolgreich geschrieben wurde.
Würde man die alte Datei direkt modifizieren, würde man bei einem Fehler beide Versionen, die alte und die neue, verlieren.

Aber "Datei speichern" bedeutet nunmal "Datei speichern".
Ein ordentliches Programm legt eine Temporäre Datei an, arbeitet in dieser und überschreibt beim Speichern dann die original.
Ich glaube eher das man hier die Existenz von hardlinks schlicht ignoriert hat.

Natürlich, es ist ein Trade-Off. Aber das muss einem bei der Verwendung von Hardlinks klar sein. Die legt man ja schliesslich nicht im Finder an.

Wo man die anlegt ist egal. OSX ist als Unix zertifiziert. Hardlinks sind unter Unixen eine ganz normale Sache.

OSX verhält sich damit NICHT Posix- und damit UNIX-kompatibel und sollte dann nicht mehr damit beworben werden.
Laut http://www.unix.org/version3/apis/t_3.html ist das link() interface mandatory

 

[below]

Mich würde es jetzt mal brennend interessieren WO dieses Verhalten für Entwickler dokumentiert ist.
Haste da mal nen link zu?

http://developer.apple.com/DOCUMENT..._ref/occ/instm/NSData/writeToFile:atomically:

Parameters
...
atomically
If YES, the data is written to a backup file, and then—assuming no errors occur—the backup file is renamed to the name specified by path; otherwise, the data is written directly to path.

OSX verhält sich damit NICHT Posix- und damit UNIX-kompatibel

An welcher Stelle?

Alex

 

[maceis]

...
Hier geht es um eine bestimmte Art der Sicherheit:

Das mag ja sein, ärgerlich ist es in vielen Situationen dennoch.
Könnte man das nicht "Besser" so umsetzen, dass zuerst ein backup-file gesichert wird und dann, wenn alles gut gegangen ist die Datei im Original-Inode gesichert wird. Wenn dabei was schiefgeht, hätte man noch die Backupdatei, die, wenn alles gut gegangen ist, gelöscht werden kann.

Zum Thema symlinks. Es gibt Programme, die solche Links auflösen und sich dann den Pfad zum source file merken. Das ist zwar außerordentlich bescheiden, zwingt einen aber in solchen Situationen hardlinks zu verwenden. Dann wiederum hat man mit dem hier diskutierten Problem zu kämpfen, was einen dazu zwingt, nach jedem Sichern die hardlinks neu zu erstellen (z.B. mit Hilfe eines Skriptes). Das ganze finde ich ziemlich ärgerlich und wenig benutzerfreundlich.

 

[below]

Das mag ja sein, ärgerlich ist es in vielen Situationen dennoch.
Könnte man das nicht "Besser" so umsetzen, dass zuerst ein backup-file gesichert wird und dann, wenn alles gut gegangen ist die Datei im Original-Inode gesichert wird. Wenn dabei was schiefgeht, hätte man noch die Backupdatei, die, wenn alles gut gegangen ist, gelöscht werden kann.

http://bugreport.apple.com

Alex