Suche Linux und OS X kompatibles Dateisystem

Hi Leute,

es mag sein dass ich etwas falsch verstanden habe, aber sehe ich das richtig, dass es relativ kompliziert ist, ganz normale Dateien (Bilder, Musik, HTML-Dateien etc.) zwischen Linux und Mac zu transferieren? Oder ist das nur eine Besonderheit dieses HFS+-Filesystems?

Wie läuft es denn dann bei FTP-Übertragungen?

PS: Ich dachte immer Ext2 etc. wären "Nichtflache"-Dateisysteme, zumindest gegenüber FAT32 etc.. Oder habe ich einfach eine falsche Vorstellung, was ein Flaches Dateisystem ausmacht?
 
Tobias_Baus schrieb:
Wie läuft es denn dann bei FTP-Übertragungen?
Zum Vergrößern anklicken....
Nur der Datenzweig wird kopiert, die Resourcen und die Metadaten gehen verloren (sowohl von HFS zu einem flachen Dateisystem, als auch zu HFS).
 
Das ist aber doch extrem unpraktisch, gibt es da denn keine "einfache" Lösung? Es muss doch mehr Leute geben, die beispielsweise einen Linux-Server zu Hause haben und ein Mac-Notebook, zwischen denen sie Daten austauschen wollen ...
 
Ext2 kann nur Dateien und ein paar Flags dazu speichern, genau wie FAT32 ;)
 
Tobias_Baus schrieb:
es mag sein dass ich etwas falsch verstanden habe, aber sehe ich das richtig, dass es relativ kompliziert ist, ganz normale Dateien (Bilder, Musik, HTML-Dateien etc.) zwischen Linux und Mac zu transferieren? Oder ist das nur eine Besonderheit dieses HFS+-Filesystems?
Zum Vergrößern anklicken....

Alle Daten in der Ressource-Fork werden gelöscht.

Das ist in der Relaität weniger tragisch als es klingt, man muß aber sehr genau wissen, was man tut:

In fast allen Fällen enthält die Ressourcefork gar nichts -> egal.

In den meisten der verbleibenden Fälle enthält die RF nur "Komfort-Daten". Also z.B. bei Classic-Illustrator-EPS-Bildern eine kleine Vorschau. Rüberziehen auf 'ne Dose = Vorschau weg, aber Bild an sich noch in Ordnung. Aufmachen in Dosen-Illustrator, wieder abspeichern, Vorschau wieder da.
Das ist auch ein typisches Beispiel aus der Praxis: Da Dosen-Illustrator das ja auch offensichtlich ohne geforkte Dateisysteme kann, funktioniert das Resultat auf beiden Plattformen - weswegen inzwischen vermehrt Mac-Software die gleichen Techniken nutzt wie ihre Win-Versionen, wodurch die Daten portabel werden und auf beiden Plattformen rennen.

In einigen Fällen enthält die RF wichtige Daten - bei klassischen Postscriptfonts liegt sogar die komplette Datei in der Ressource. Rüberziehen -> kaputt.


Für den Netzwerkbetrieb gibt es unter Linux netatalk. Das simuliert im Netz einen Apple-Fileserver. Auf dem Linux-Server werden dann einfach beiden Forks in getrennten Dateien gespeichert, der Mac sollte davon nichts bemerken:

meineDatei.xyz
.AppleDouble/.meineDatei.xyz

...wird beim "liefern" wieder zusammengesetzt.


Was nur mit Basteln geht, ist, daß Fremdsysteme an die RF rankommen - der Fall ist aber theoretisch, mir fällt dazu kein Anwendungszweck ein.




Tobias_Baus schrieb:
Wie läuft es denn dann bei FTP-Übertragungen?

PS: Ich dachte immer Ext2 etc. wären "Nichtflache"-Dateisysteme, zumindest gegenüber FAT32 etc.. Oder habe ich einfach eine falsche Vorstellung, was ein Flaches Dateisystem ausmacht?
Zum Vergrößern anklicken....

FTP killt die RF.
Als "Flache Dateisysteme" (was meines Wissens keine offizielle Bezeichnung ist) gilt eigentlich alles ausser HFS(+) und NTFS5 (Bei NTFS4 weiss ich es nicht). Mir wäre kein anderes FS bekannt, welches Streams unterstützt.

Ehrlich gesagt: Ich weiss auch gar nciht, was man damit will. Ich bin eher daran interessiert, daß ich mehrere Plattformen zur Zusammenarbeit bewegt kriege, und solche verspielten Goodies sind doch echt Quatsch. Das hätte man technisch auch anders lösen können - aber das kommt wohl noch aus Zeiten, als an interoperabilität noch keiner gedacht hat. Was mich ärgert, ist, daß Apple jawohl die Ankündigung zurückgezogen hat, die RF sterben zu lassen. Argh! Bringt das Teil um! SCHNELL!... :-(

Gruß,
Ratti
 
@ Tobias_Baus
Wenn Du es von der GUI des Macs aus machst (über NFS oder auch Samba), gibt es keine Probleme.
 
Danke, aber noch 2 Fragen:

Gibt es eine Möglichkeit - für den unerfahrenen Anwender - vor dem Kopieren auf einen Linux-Server zu überprüfen, ob die Daten es überstehen werden?

Und gibt es ein Tool o.Ä. um die Daten für den Kopiervorgang vorzubereiten, damit dieser Datenverlust nicht auftritt?

Vielleicht kurz zu meiner Situation: Ich benutze momentan Linux, und würde dies auch gerne weiter auf einem Rechner benutzen (momentane Überlegung: ein Linux-Server, unter anderem zur Dateiablage). Dazu will ich mir vielleicht ein iBook holen, vorallem weil ich ab Sommer anfange zu studieren. Nur würde ich die Daten gerne auf meinem Linux-Server dauerhaft ablegen, so dass sie auf dem Mac "nur" bearbeitet werden. Allerdings fällt das Vorhaben weitestgehend flach, wenn ich mit eventuellem Datenverlust rechnen muss.

[edit] Verdammt, jetzt hab ich ganz deine Antwort übersehen, ._ut. Dann hat sich das ja eigentlich erledigt, danke. :) [/edit]
 
Zuletzt bearbeitet:
Tobias_Baus schrieb:
Vielleicht kurz zu meiner Situation: Ich benutze momentan Linux, und würde dies auch gerne weiter auf einem Rechner benutzen (momentane Überlegung: ein Linux-Server, unter anderem zur Dateiablage). Dazu will ich mir vielleicht ein iBook holen, vorallem weil ich ab Sommer anfange zu studieren. Nur würde ich die Daten gerne auf meinem Linux-Server dauerhaft ablegen, so dass sie auf dem Mac "nur" bearbeitet werden.
Zum Vergrößern anklicken....

Nur kurz zur inhaltlichen Klarstellung: Wenn die Dateien von einem Mac geschrieben werden, dann "merkt" der Mac, daß das Zielsystem kein HFS+ ist und splittet die Datei auf. Wenn man die Daten öffnet, setzt er sie wieder zusammen. Also kein Problem.

Was NICHT geht:

- Daten vom Mac aus draufschieben
- Daten auf dem Server durch dessen Programme verändern
- Daten zurück auf den Mac holen.

Das ist insbesondere für Backups interessant, die ja i.d.R. auf dem Server laufen sollen. Druch die Zerlegung in zwei Files ist eine konsistenz nicht garantierbar.

Wenn die Daten auf dem Server von dessen Programmen gar nicht angefasst werden, hast du nicht viel zu befürchten.

Gruß,
Ratti
 
Kurzes Gedankenspiel:

2 Leute arbeiten an einem Projekt, einer mit Mac OS und der Andere mit sagen wir mal Linux. Sie schicken sich die Projektdateien per E-Mail zu, und bearbeiten sie auch beide mit zueinander kompatiblen Programmen (z.B. beide mit OpenOffice). Würde das funktionieren?


Sorry, ich hab die Frage praktisch ja eben schon gestellt, aber irgendwie bin ich gerade verwirrt. :(
 
Tobias_Baus schrieb:
Kurzes Gedankenspiel:

2 Leute arbeiten an einem Projekt, einer mit Mac OS und der Andere mit sagen wir mal Linux. Sie schicken sich die Projektdateien per E-Mail zu, und bearbeiten sie auch beide mit zueinander kompatiblen Programmen (z.B. beide mit OpenOffice). Würde das funktionieren?


Sorry, ich hab die Frage praktisch ja eben schon gestellt, aber irgendwie bin ich gerade verwirrt. :(
Zum Vergrößern anklicken....

Warum sollte das nicht gehen?
 
Ja aber warum ist es denn dann so kompliziert, Datei zwischen Mac und Linux direkt per Netzwerk auszutauschen und auf beiden zu bearbeiten? Oder habe ich die ganze Zeit an euch vorbei geredet?
 
hermann4000 schrieb:
hat fat32 nicht den nachteil irgendwelcher partitions-größen-grenzen?
wollte mir bald ne 250er externe platte zulegen und die gedankenlos
- und möglichst mit nur einer partition, bin faul - überall nutzen können :)
Zum Vergrößern anklicken....
Damit nicht: ;)
 
Tobias_Baus schrieb:
Ja aber warum ist es denn dann so kompliziert, Datei zwischen Mac und Linux direkt per Netzwerk auszutauschen und auf beiden zu bearbeiten? Oder habe ich die ganze Zeit an euch vorbei geredet?
Zum Vergrößern anklicken....

Kompliziert wird es bei

a) Programmen, die Ressource Forks nutzen,
b) um darin wichtige Daten abzulegen (keine Goodies)

Diese Kombi ist recht selten.
Im wesentlichen betrifft es Systemkomponenten des alten 9er Systems, z.B. PS-Fonts. Oder Programme.

Mit anderen Worten: Es tritt selten als Problem auf - und wenn, betrifft es meistens Dateien, mit denen die andere Plattform überhaupt nicht anfangen kann. Ein Linux-Rechner könnte keine Mac-Programme starten, und klassische Mac-Fonts laufen ebenfalls auf keinem anderen System.

Man sollte wissen, was man da tut - aber ein alltägliches Problem ist das nicht.

Gruß, Ratti
 
Achso ist das. Dann ist ja gut. Super, danke für eure Hilfe. :)
 
Hallo,

jetzt möchte ich auch gerne nochmal nachhaken. Ich hoffe ich habe das nach lesen dieses Thread eingermassen verstanden.

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?

Wenn ich z.b. (wie ich es tat) meine CDs auf meinem Mac konvertiere und auf dem Fileserver ablege, dann tauchen dort ja die "ressource forks" auf. Kopiere ich diese Ordner auf das Notebook werden die mitkopiert. Das finde ich zwar nicht wirklich schlimm allerdings auch überhaupt nicht schick.

Nun komme ich z.b. auf die Idee auf dem Notebook die mp3-Tags zu ändern und kopiere die Files (über den Server oder direkt) wieder auf den Mac. Sind meine neuen Tags dann weg oder die mp3s schlicht im Eimer?

Anderes Szenario: ich bekomme auf der Arbeit von einem Kollegen z.b. eine Word-Datei auf mein Notebook geschoben. Auf dem Notebook habe ich kein Office, was für mich heisst ich müsste die Dokumente auf den Mac schaffen (direkt oder über den Server) um sie dort mit z.b. NoeOffice zu bearbeiten. Ich kopiere die bearbeiteten Daten wieder auf das Notebook und von da wieder auf den Rechner des Arbeitskollegen. Sind die Daten noch brauchbar? Müsste ich für jedes File jeweils abwägen ob das gut gehen wird? Oder würden halt einfach nur "ressource forks" erstellt die ich komplett ignorieren kann (evtl. einfach lösche)? Und gibt es im Ergebniss einen Unterschied wenn mein Arbeitskollege einen Mac oder einen PC nutzt?

Mir scheint gerade das es keine wirkliche Lösung zum Datenaustausch (mit Datenbearbeitung) zwischen Mac und PC gibt, man also darauf angewiesen ist seine Daten (unterschiedlicher Herkunft; PC bzw. Mac) so zu sortieren das sie sich schlicht nicht mischen. Liege ich da in etwa Richtig?
 
meeb schrieb:
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
Zum Vergrößern anklicken....
 
@ratti

vielen Dank für deine Mühe. Nun ist mir das nochmal deutlich klarer geworden. Ich werde somit schlicht für die Daten der einzelnen Rechner einzelne Ordner anlegen und deine Tipps zu den Dateinamen beherzigen.

Da mein Fileserver nur mich bedient läuft der nur wenn ich ihn brauche, daher wäre ein cron-job eher nicht so sinnvoll. Mich würde jedoch trotzdem interessieren mittels welchen Befehls Du die ._-files löscht. Ich denke daran zumindest die Ordner mit Daten die nicht auf "ressource forks" angewiesen sind (z.b. die mp3s) zu "säubern".
 
meeb schrieb:
Da mein Fileserver nur mich bedient läuft der nur wenn ich ihn brauche, daher wäre ein cron-job eher nicht so sinnvoll. Mich würde jedoch trotzdem interessieren mittels welchen Befehls Du die ._-files löscht. Ich denke daran zumindest die Ordner mit Daten die nicht auf "ressource forks" angewiesen sind (z.b. die mp3s) zu "säubern".
Zum Vergrößern anklicken....

Aus dem Kopf:

find /data/ -type f -iname '._*' -exec rm -rf "{}" \;

/data/ ist natürlich entsprechend zu ersetzen. Um solche Konstrukte erstmal zu testen, einfach "rm -rf" durch ls ersetzen:

find /data/ -type f -iname '._*' -exec ls "{}" \;

EDIT:
Grr... das ist falsch, weil es Verzeichnisse falsch anzeigt. In diesem Fall werden zwar sowieso nur Files gesucht (-f), trotzdem sollte man es sich richtig angewöhnen, mit "-d":

find /data/ -type f -iname '._*' -exec ls -d "{}" \;

Gruß,
Ratti
 
Zuletzt bearbeitet:
vielen Dank, das hilft
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten