(27. Februar 2004 — tk)

Wie werden intern Mac-Dateien gespeichert?

Netatalk spaltet Dateien, die von einem Mac kommen, physisch in jeweils zwei Dateien im Dateisystem auf:

  • Die eigentliche Datei enthält die sogenannte Data Fork
  • Im Unterordner .AppleDouble befindet sich noch eine korrespondierende Datei, die einerseits Finder Metadaten enthält und — falls die Datei eine Resource Fork besitzt — jene ebenfalls. Seit Netatalk 2.0 werden auch noch zusätzlich Metadaten des afpd gespeichert — siehe weiter unten.

Netatalk vor Version 2.0 benutzte für die Speicherung das sogenannte AppleDouble Format in Version 1 (siehe auch AppleDouble v1 Format Spezifikation )

Ab Version 2.0 benutzt Netatalk hingegen Version 2 der Spezifikation — kurz ADv2 (siehe auch AppleDouble v2 Format Spezifikation ). Trifft der afpd auf AppleDouble-Dateien im alten v1 Format, so werden diese automatisch — und nicht rückkonvertierbar! — nach Version v2 gewandelt.

Die Gründe für die Wahl von v2 waren einerseits die Möglichkeit, die Directory ID als Teil des Formats mitzuspeichern und andererseits private Felder in den AppleDouble Header Dateien zu benutzen, um zusätzliche Informationen unterzubringen.

Von letzterem macht Netatalk 2.0 folgendermaßen Gebrauch: Es werden noch 4 zusätzliche private Felder mit den IDs 2151957846, 2152287823, 2152945998 und 2152945278 benutzt, um Device/Inode-Informationen, einen CNID-Stamp und die File-ID respektive Directory-ID zu speichern.

Dies ermöglicht es, die ADv2-Dateien im .AppleDouble-Verzeichnis für folgende Zwecke zu benutzen:

* ID-Cache, um die (langsamen) Zugriffe auf die BerkeleyDB-basierten CNID-Datenbanken zu minimieren * Änderungen, die außerhalb des afpd-Einflußbereichs geschehen sind (bspw. durch Samba), leichter nachvollziehbar * Kompletter Neuaufbau der CNID-Datenbanken anhand der ID-Informationen — nützlich bspw. nach einer Crash-bedingten Datenbank-Korruption

Zusätzlich werden noch die folgenden offiziellen Felder mit den IDs 3, 4, 8, 9, 14 und 15 genutzt. Und natürlich noch ID 2, in der eine evtl. vorhandene Resource Fork untergebracht wird:

* ID 3 (Real Name) Nicht vom afpd benutzt aber von einigen 3rd Party Anwendungen * ID 4 (Comment) Kommentarfeld für MacOS 9 Clients, die Finder-Kommentare als Teil der Finder-Info unterbringen. MacOS X benutzt dafür hingegen die .DS_Store-Dateien * ID 8 (File Dates Info) 3 Mac-Zeitstempel (create, modify und backup) * ID 9 (Finder Info) Die sogenannte »Standard Macintosh Finder Information« * ID 14 (AFP File Info) Datei-Attriute wie bspw. »unsichtbar«, »geschützt«, etc. * ID 15 (Directory ID) Die DID des »Parent Directory«

Obiges gilt aber nur, solange man nicht per adouble:osx-Eintrag in der AppleVolumes.default-Datei das verkrüppelte ADv2-Schema erzwingt, das Apple mit MacOS X eingeführt hat. Letzteres ist lediglich sinnvoll, wenn man per Netatalk bspw. FAT32-formatierte Firewire-Platten, die vorher direkt an einem Mac beschrieben wurden, freigibt (nur in diesem Fall bzw. wenn MacOS X auf FAT-/NFS-/SMB- oder andere »flache« Dateisysteme schreibt, kommt dieses Schema zum Tragen).

Das adouble:osx-Schema, das lediglich die IDs 2 (Resource Fork) und 9 (»Finder Info«) unterstützt, ist ansonsten generell zu vermeiden, da es sowohl die mit Netatalk 2.0 neuen Möglichkeiten des afpd beschneidet (siehe oben) als auch Kompatibilität zu MacOS 9 bricht (Finder-Kommentar kann nicht geschrieben werden). Bei weiterem Interesse ist die diesbzgl. entstandene Diskussion über Datei-Kompatibilität auf der Netatalk-Entwicklerliste recht interessant.

Copyright © Thomas Kaiser, 2008 (erstellt 27. Februar 2004 — tk)

Dieser Beitrag kann durch jedermann gemäß den Bestimmungen der Lizenz für die freie Nutzung unveränderter Inhalte genutzt werden. Die Lizenzbedingungen können unter http://www.uvm.nrw.de/opencontent abgerufen oder bei der Geschäftsstelle des Kompetenznetzwerkes Universitätsverbund MultiMedia NRW, Universitätsstraße 11, D-58097 Hagen, schriftlich angefordert werden.