Mac Frisst Dateien

Also: Die Datei lag mit sauberen Namen auf dem Schreibtisch. Und das "Apfel + S" ist eine Routine nach jahrelangem Nutzen von Rechnern. Und ich habe alle Tipps durchproiert. Fazit: Die Datei scheint im Nirvana zu sein. Seufz.
 
jcm schrieb:
Also: Die Datei lag mit sauberen Namen auf dem Schreibtisch. Und das "Apfel + S" ist eine Routine nach jahrelangem Nutzen von Rechnern. Und ich habe alle Tipps durchproiert. Fazit: Die Datei scheint im Nirvana zu sein. Seufz.
Zum Vergrößern anklicken....
Es würde mich nicht wundern wenn es an der seltsamen Verfahrensweise liegt wie mac-Programme Dateien öffnen: Die öffnen nämlich eine Kopie und speichern am Ende eine neue Datei ab. Das bedeutet das nach jedem Speichern eine neue Datei erzeugt wird. Wenn dazwischen was schief geht könnte das tatsächlich zu Datenverlusten führen. Dieses Problem wäre dann direkt apple anzulasten und ist dort schon seit langem bekannt.
 
magheinz schrieb:
Es würde mich nicht wundern wenn es an der seltsamen Verfahrensweise liegt wie mac-Programme Dateien öffnen: Die öffnen nämlich eine Kopie und speichern am Ende eine neue Datei ab. Das bedeutet das nach jedem Speichern eine neue Datei erzeugt wird. Wenn dazwischen was schief geht könnte das tatsächlich zu Datenverlusten führen. Dieses Problem wäre dann direkt apple anzulasten und ist dort schon seit langem bekannt.
Zum Vergrößern anklicken....

Wenn du auf die Feststellungen mit den Hardlinks anspielst, das hat nichts mit dem Betriebssystem selbst zutun. TextMate macht das nämlich korrekt (Hardlink bleibt beim Speichern bestehen, es wird also keine neue Datei erzeugt), obwohl es den Cocoa-Standard-Dialog verwendet.

Grundsätzlich bietet das Betriebssystem nur eine Funktion zum Erstellen von Filedescriptoren an. Es obliegt dem Programm, das die Dateien bearbeitet, damit umzugehen.

Mit einem hast du recht, während des Abspeichern ist etwas schief gelaufen. Ich glaube aber nicht so recht an eine Schuld von MacOS. JCM sagte ja auch, dass die Datei aus dem Verlauf von Office verschwunden ist, als hätte es damit nie zutun gehabt..
 
_ebm_ schrieb:
Wenn du auf die Feststellungen mit den Hardlinks anspielst, das hat nichts mit dem Betriebssystem selbst zutun. TextMate macht das nämlich korrekt (Hardlink bleibt beim Speichern bestehen, es wird also keine neue Datei erzeugt), obwohl es den Cocoa-Standard-Dialog verwendet.
Zum Vergrößern anklicken....
Tue ich, richtig erkannt :)
Das TextMate korrekt arbeitet wusste ich jetzt nicht.

_ebm_ schrieb:
Grundsätzlich bietet das Betriebssystem nur eine Funktion zum Erstellen von Filedescriptoren an. Es obliegt dem Programm, das die Dateien bearbeitet, damit umzugehen.
Zum Vergrößern anklicken....
Naja, es gibt ja offensichtlich einige Programme die ein massives Problem damit haben. Ob das Problem dabei am OS oder am Programm liegt wird vermutlich nur apple herausfinden können. Da aber auch appleeigne Tools betroffen sind tippe ich immer noch stark auf das OS und seine APIs als Ursache. Wenn ich mir vorstelle das Offcie es genau wie TextEdit macht, dann ist es kein Wunder. dann wird bei jedem autosave eine neue Datei angelegt. Wenn jetzt zwischen diesen Autosaves das Programm wegbricht, dann exitsiert da eine komplett neue Datei.

filehandler(datei1) ist offen -> autosave erfolgt -> filehandler(datei2) ist offen.
Wenn jetzt der crash vor dem nächsten save erfolgt dürfte die Datei weg sein.

Das ist nur eine Vermutung, zumindest wäre das aber eine Möglichkeit.
 
magheinz schrieb:
Wenn ich mir vorstelle das Offcie es genau wie TextEdit macht, dann ist es kein Wunder. dann wird bei jedem autosave eine neue Datei angelegt.
Zum Vergrößern anklicken....

Wenn ich mich an den Thread richtig erinnere, war das Verhalten nicht gleich. TextEdit löste den Hardlink auf, Office hat ihn korumpiert.

magheinz schrieb:
filehandler(datei1) ist offen -> autosave erfolgt -> filehandler(datei2) ist offen.
Wenn jetzt der crash vor dem nächsten save erfolgt dürfte die Datei weg sein.

Das ist nur eine Vermutung, zumindest wäre das aber eine Möglichkeit.
Zum Vergrößern anklicken....

Ein Filehandler ist eigentlich nur ein verweis auf den INODE. Das Kopieren der Datei beim Bearbeiten soll ja eigentlich vor Datenverlust schützen.

1) Datei öffnen (fd0)
2) Neue Datei erzeugen,die alte existiert noch open(fd1)
3) filecopy(fd0,fd1)
4) fd0 sollte danach geschlossen werden. fd1 ist vorerst eine temporäre Datei
5) Alle weiteren Operationen erfolgen auf fd1, das sichere Original liegt noch in der Originaldatei
6) fd1 autosafe geschieht auf der temp. Datei
7) Zum Sichern durch den Benutzer wird ein neuer fd2 erzeugt, der auf den Namen der Originaldatei verweist. Hier scheint ein es Implementierungsfehler zu geben. TextEdit löscht das alte original, da es vorhanden ist und erzeugt danach eine neue Datei. Das Ergebnis ist zwar "sauber", jedoch bricht es die Hardlinks. Richtig wäre es, das alte Original als bestehende Datei zu öffnen und dann mit filecopy den Inhalt dort hinüber zu kopieren. Office wird wohl noch was ganz anderes machen, wer weiss was. Was liefert eigentlich das OpenFile-Widget von Cocoa zurück? Naja,das ist offtopic..

Gruss Carsten
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten