Ich habe hier meinen alten PC unter OpenBSD als Fileserver (auf dem z.Z. FTP und Samba angeboten werden), dazu habe ich ein Notebook auf dem ebenfalls ein OpenBSD tut und einen Mac auf dem Mac OS X schafft.
Wenn ich nun Daten von beiden Client-Rechnern auf dem Server ablegen will, muss ich darauf achten das die sich nicht mischen? Also für die Backups vom Mac und für die Backups vom Noteboot jeweils einen eigenen Ordner anlegen?
Ja, das ist ein gewisser Nerv-Faktor...
Szenario 1:
Du kopierst die Datei "egal.mp3" vom Mac auf den Server.
Der Mac "merkt", daß er auf dem Server ein flaches Filesystem vorfindet.
Er speichert die Data-Fork als "egal.mp3".
Er speichert die Ressource-Fork als "._egal.mp3"
Du bastelst auf dem Server rum (oder auf einem anderen nicht-Mac) und veränderst die Datei "egal.mp3". Weder der Server noch dein Nicht-Mac-Client interessiert sich irgendwie für die Datei "._egal.mp3", da besteht für andere OSse überhaupt keine Verbindung.
Du holst die Datei auf den Mac zurück:
Der Mac "merkt", daß er auf dem Server ein flaches Filesystem vorfindet.
Er speichert "egal.mp3" als Data-Fork.
Er speichert "._egal.mp3" als Ressource-Fork.
Die Datei auf deinem Mac enthält also die neue mp3-Datei mit der alten Ressourcefork.
Was das jetzt für die Daten bedeutet, ist eine gute Frage... von "Macht nix" bis "Blödsinn" ist prinzipiell alles drin.
Szenario 2:
Wie oben, aber du sicherst die mp3-Datei nach dem ändern auf dem Server unter einem ANDEREN Namen, "totalegal.mp3"
Du holst die Datei auf den Mac zurück:
Der Mac "merkt", daß er auf dem Server ein flaches Filesystem vorfindet.
Er speichert "totalegal.mp3" als Data-Fork.
Er findet keine Datei "._totalegal.mp3", die Datei enthält keine Ressource-Fork.
Genau das ist die Situation, wenn du dir z.B. eine mp3-Datei aus dem Web downloadest. Da ist ja auch keine Ressource-Fork dran.
Alles prima.
Szenario 3:
Du nimmst einen klassischen OS-9-PostScriptfont und legst ihn auf den Server. Die Datei heisst "HelveConBol" für "Heveltica Condensed Bold".
Der Mac "merkt", daß er auf dem Server ein flaches Filesystem vorfindet.
Er speichert die Data-Fork als "HelveConBol".
Er speichert die Ressource-Fork als "._HelveConBol"
Der Unterschied zu Szenario 1: Bei solchen Dateien liegen alle Relevanten Daten in der RESSOURCE-Fork. Die normale Data-Fork ist leer!
Du schaust mit deinem BSD-Client auf den Server. Du siehst eine Datei:
HelveConBol: 0 Bytes.
Wenn du an der Datei jetzt rumschiebst oder rumbenennst, findet der Mac die zugehörige Datei "._HelveConBol" nicht wieder -> Totalschaden.
Es gilt die Einschränkung: Warum SOLLTEST du überhaupt an dieser Datei rumschieben? Es kann ja doch keine andere Plattform was damit anfangen. Soweit ist das also schonmal von geringerem Interesse.
ABER:
Wenn jetzt auf deinem Server ein Backup läuft, müsste man für ein Restore natürlich immer BEIDE Dateien wiederholen. Es gibt sicherlich noch mehr Beispiele, wo sowas zu beachten wäre.
Was dir grundsätzlich dabei passieren kann, ist, daß dir der Dateityp und creator verloren geht. Dann ist eine Datei "egal" plötzlich vom Typ "Dokument" und hat das Weisse-Blatt-Papier-Icon, statt korrekterweise ein Tiff aus Photoshop zu sein.
Deswegen verwende ich GRUNDSÄTZLICH Extension ("egal.tif"). Um Typ und Creator zu reparieren, kann man "GetFileInfo" und "SetFile" aus dem Developertools-Paket verwenden. Meistens braucht man das nicht, weil z.B. Photoshop auch ein "unbekanntes" Dokument richtig öffnet, wenn der Name auf "tif" endet. Machen Programme sind aber eigen - z.B. musste ich gerade ganz viele xtg-Dateien für Quark reparieren:
/Developer/Tools/SetFile -c xpr3 -t text *.xtg
weil Qark auf dem Typ besteht und sich durch den Dateinamen "text.xtg" nicht davon abbringen lässt (Quark4).
Das nur als Beispiel. Ein generelles "Geht/Gehtnicht" gibt es nicht - alle hängt vom Dateityp ab, von der verwendeten Software, vom KnowHow des Bedieners, ...
Der Kollege zählt als Mac?
Er kopiert "egal.doc" auf dein Notebook (BSD). Dabei generiert Mac OS X die Dateien
egal.doc
._egal.doc
Szenario 1:
Du ziehst zuhause mit deinem Mac die Daten wieder runter. Der Mac kombiniert beide Files. Alles gut. Du bearbeitest die Datei und schiebst sie unter dem gleichen oder anderen Namen zurück. Und weiter zum Kollegen. Alles prima.
Szenario 2:
Du ziehst dir zuhause die doc-Datei mit einem BSD-Client.
BSD interessiert sich ausschliesslich für egal.doc und ignoriert ._egal.doc.
Du bearbeitest die Datei mit OpenOffice, exportierst als doc-Datei und schiebst sie zurück...
- Möglichkeit 1: Wenn du den gleichen Dateinamen verwendest, wir der Mac die aktuelle Datei mit der alten Ressource kombinieren. Vermutlich wird das klappen, aber eine üble Mixtur ist das schon. Möglicherweise wird das Dokument zum Beispiel das Etikett oder den Dateikommentar vom alten Word-Dokument übernehmen. Bei einem EPS würde die Preview das alte Dokument zeigen, gedruckt würde aber das neue. Schon wurstelig, irgendwie.
- Möglichkeit 2: Du sicherst unter neuem Dateinamen zurück. Gut - Word-Dokumente brauchen keine Ressourcefork. Der Kollege holt sich die nackte Data-Fork als Word-Dokument. Möglicherweise öffnet sie nciht auf Doppelklick, sondern muß über "Öffnen mit" geöffnet werden - es ist aber alles in Ordnung, und wenn der Kollege neu speichert, hat er auch wieder ein rundum "Mac"-iges Word-Dokument.
Das Problem hat man immer, wenn man in gemischten Umgebungen arbeitet.
Stell dir vor, du hast 10 Mac-Clients, 10 Win-Clients, 10 Linux-Clients und auf dem Server würde sogar OS X laufen.
Das würde soweit gut funktionieren - aber nichts daran ändern, daß die Win/Lin-Leute den Maccies die Ressourcen zerballern.
Das ist nunmal prinzipbedingt: Wer proprietäre Features einbaut, hat die Freude des Mehrwerts - bis die Daten bei Cross-Plattform-Arbeiten das erste mal durch die Mühle der kleinsten Gemeinsamkeit gemangtelt werden. Dann ist das Geschrei groß.
Mein persönlicher Arbeitsstil: Dateinamen maximal 31 Buchstaben, als Zeichen nur a-z._ , und wenn es irgend geht: Keine Software verwenden, die auf "Forks" oder "Filetypes" angewiesen(!) ist.
Auf unserem Entwicklungsserver sind wir da rigoros:
Alle volle Stunde brettern ein cronjob drüber und löscht "._*". Wessen Daten hinterher kaputt sind, der hat seine Lektion JETZT gelernt und nicht erst, wenn beim nächsten Plattencrash die restaurierten Daten trotzdem nicht laufen.
Gruß, Ratti