Linux kann zur Zeit nur HFS mounten, nicht aber HFS+. Zum Mounten von HFS-Volumes gibt es zwei Möglichkeiten:
Dies ist die elegante aber etwas unsichere Methode: Man kann in den Kernel support für HFS-Partitionen einkompilieren. Bei LinuxPPC, Mklinux etc. ist diese standardmässig bereits geschehen. Man kann nun (als root) entweder mit
> mount /dev/xyz /mac
eine HFS-Partition auf /mac mounten. Dabei muss xyz (wie auch im weiteren) durch den entsprechenden device der HFS-Partition ersetzt werden, also sowas wie hda5 , hdb8 , sda3 etc. (siehe auch Wie mountet man ZIPs/CDs oder andere externe Medien?). Und das Verzeichnis /mac muss vorher erzeugt worden sein (z.B. mit > mkdir /mac). Man kann dies auch automatisch bei jedem boot machen lassen. Dazu fügt man in der /etc/fstab ein Zeile ähnlich der folgenden ein:
/dev/xyz /mac hfs defaults 0 0Mit der Zeile
/dev/xyz /mac hfs defaults,noauto,user 0 0
kann man erreichen, dass diese Partition beim booten nicht gemountet wird, später aber von jedem user (also nicht nur root) mit
> mount /macgemountet werden kann.
Leider ist der hfs-Support nicht ganz bugfrei, so dass man zur Sicherheit das ganze nur readonly mounten sollte. Das fügt man in der /etc/fstab bei den Optionen die Option ro ein, also z.B.
/dev/xyz /mac hfs defaults,noauto,user,ro 0 0oder beim mounten mit der Option -r:
> mount -r /mac
Das ganze ist halt elegant, weil die HFS-Partition vollständig in den Dateibaum integriert ist. Wegen der Bugs kann man sich aber dabei leider das HFS-Dateisystem auf dieser Partition zerschiessen. Bei readonly-gemountete Partitionen sind mir keine Probleme bekannt.
Ein Möglichkeit besteht darin eine kleine
MacOS-Linux-Exchange- Partition anzulegen (je nach Platte und Datenbedarf 32-128 MB) und diese dann
readwrite-Fähigkeit. Über diese Partition werden nun Daten zwischen MacOS und Linux
ausgetauscht. Daher liegen hier nie Daten, die nicht noch an derer (sicherer) Stelle liegen.
Deshalb ist es zwar ägerlich, wenn das HFS-Dateisystem dort mal kaputt geht, aber kein Drame.
Der Nachteil dieses Verfahrens ist jedoch, dass man von Linux aus zwar leicht Daten zum MacOS schieben kann,
aber keine Daten von dort ziehen kann, ohne dass man vorher unter MacOS die Daten auf die Exchange-Partition
geschoben hat.
Da aber in Zunkunft wahrscheinlich alle Partitionen un ter MacOS unter HFS+ laufen werden, ist bis zum Erscheinen eine hfs+-Kernel-Moduls sowieso eine Exchange-PArtition unter FS die einzige Möglochkeit von Linux aus an daten vom MacOS zu kommen.
Diese sind etwas umständlich aber sicher. Die hfstools sind eine Sammlung kleiner Programme, mit denen amn auf HFS-Partitionen zugreifen kann. Dabei mountet man eine HFS-Partition in einem eignen Modus, der nur für die anderen hfs-tools zugänglich ist. Das ganze geht mit
> hmount /dev/xyzxyz gibt wieder den device-File an. Mit
> humount
hebt man den mount wieder auf. Ein weiterer hmount ohne eine humount zwischendurch, wirkt wie ein humount mit folgendem hmount. Mit
> hdir
kann man sich dann das aktuelle Verzeichnis auf der HFS-Partition anzeigen lassen. Mit
> hcd path
kann man den Pfad auf dem HFS-Volume wechseln (Es geht beim Pfad hier die MacOS -Konventionen, also Pfadtrenner ist der ':' etc.) Mit
> hcopy Quellpfad Zielpfad
Kann man Dateien in beide Richtungen kopierern, wobei der HFS-Pfad mit einem ':' beginnen muss. Damit Leerzeichen etc. in HFS-Dateinamen richtig ausgewertet werden (Nälich als Teil des Dateinamens), sollte man die HFS-Pfade immer in '"' schreiben. Dann kann man dort auch mit wildcard '*' arbeiten. Dann muss das Ziel aber eine Verzeichnis bezeichnen. Um wildcards in HFS-Namen zu verwenden, muss der HFS-Dateiname in '"' gesetzt werden.
Ich persönlich bevorzuge die hfstools, wegen der etwas Linux-unverträglichen Namen unter HFS. Man achtet bei den hfstools mehr auf diese Tatsache. Ausserdem können die hfstools bei hcopy gleich eine Anpassung der Zeichensätze und Zielenenden bei Textdateien vornehmen.
Und noch eine Bemerkung zum Schluss. Bei einer Suche in den LinuxPPC-Mailinglisten bin ich auf folgendes gestossen: Mit dem Kernel 2.4 soll einige Änderungen in der internen Filesystemstruktur kommen. Da der Entwickler des hfs-Moduls offenbar keine Zeit hat das Modul anzupassen, kann es passieren, das es vorerst wieder heraus fliegt. Auch für eine HFS+-Modul scheint die Kompetenz, was HFS+ und Kernel-Programmierung betrifft, sich nicht ein einer Person oder einer Gruppe vereinigen zu lassen.
Update: April 2000
Mittlerweile scheint es ein Projekt zu geben ein hfs+-Modul zu entwicklen. Dies Sache steckt aber noch sehr
in den Kindserschuhn. Immerhin ein Silberstreif am Horizont.