Das wird ja ganz schön metaphysisch hier...
Echt? Mit was für einem MIME-Type versendet Mail.app denn sowas?
Sorry, Deine Fragen hatte ich überlesen. Mail verschickt sowas als "Content-Type: application/applefile". Es gibt sogar ein RFC, nämlich RFC-1740 dafür.
Und ist das Format, das Mail.app dabei verwendet, irgendwo dokumentiert?
Ja, es wird das sogenannte "AppleDouble"-Format verwendet. Es gibt dazu eine Apple Developer Note, die allerdings so alt (16 Jahre) ist, dass sie in der aktuellen Xcode-Dokumentation nicht mehr enthalten ist. Aber man kann noch drankommen. Suche mal mit einer Suchmaschine nach "AppleSingle/AppleDouble Formats for Foreign Files".
Unter OS X steht im Ressource Fork ... Bitte ausfüllen ...
Naja, darauf könnte ich antworten: Hoffentlich nichts
Das gibt ja nur Scherereien, wie man an dieser Diskussion sieht.
Eigentlich kümmert sich ja das Betriebssystem ja gar nicht darum, was im Resource Fork drinsteht. Es ist Sache desjenigen Programms, das eine Datei anlegt, was es in den Resource Fork schreibt. In Mac OS X selbst gibt es meines Wissens nur noch ein einziges Programm, das Resource Forks benutzt, nämlich den Finder. Und zwar in folgenden Fällen:
- Wenn man einen Alias anlegt, dann stehen die Hilfsdaten, die der Alias-Manager später braucht, um die eventuell verschobene Originaldatei wiederzufinden, im Resource Fork des Alias.
- Wenn eine Datei ein Sonder-Icon hat, dann stehen die Bilddaten dieses Icons im Resource Fork der Datei.
Fremde Programme, die Resource Forks anlegen wollen, werden von Mac OS X natürlich nicht daran gehindert. Aber das ist dann deren Problem, wozu der Fork genutzt wird.
Und der Einsatz von Resource Forks bringt in der heutigen vernetzten Welt eben einige Probleme, da sie immer mit viel Mühe (wie diesen "._"-Dateien) emuliert werden müssen, wenn sie das HFS-Dateisystem verlassen.
Das mit dem Icon ist zweiteilig: Die Information,
dass ein Icon da ist, steht in den von mir angesprochenen Finder-Attributen, das Bildchen selber aber im Resource Fork. Wie hier auch schon angesprochen wurde, haben Grafikprogramme aus der "alten Welt" oft den Trick benutzt, die Vorschau einer Bilddatei in das Icon der Bilddatei zu speichern. Ist heute eigentlich nicht mehr nötig, da die Rechner schnell genug sind, die Bilddatei zu öffnen und die Vorschau "on the fly" zu berechnen. Datenformate wie JPEG haben sogar (mehrere) Möglichkeiten ein vorbereitetes Vorschaubild bereits innerhalb des "eigentlichen" Bildes - also im Datenfork - mitzubringen. Da muss dann auch nichts berechnet werden.
Die Type/Creator-Information sind nur 8 Bytes. Alleine dafür einen Resource Fork anzulegen, wäre Overkill. Das liegt deshalb woanders, nämlich in den besagten Finder-Attributen, die das HFS-System direkt zusammen mit den Dateinamen, Berechtigungen, etc. in einer sogenannten "CatalogInfo" speichert. Zu den weiteren Finder-Attributen gehören konkret die x/y-Position des Icons, ob es sich um eine Macintosh-"Sonderdatei" (Alias, Bundle, Formularblock, INIT-Resource, Systemdatei) handelt, ob die Datei versteckt oder gelockt ist, ob die File-Extension verborgen werden soll, die Etikettenfarbe (Finder-Label) und viele andere ähnliche Kleinigkeiten.
Der Kommentar zu einer Datei steht wieder ganz woanders, nämlich in den berüchtigten ".DS_Store"-Dateien. Wie das im alten Mac OS war, weiß ich nicht. Möglicherweise in einer Art "Ordner-Resource-Fork"..?
Unter Windows kann jede Datei auch neben dem normalen Datenteil noch weitere (jetzt weiß ich aktuell nicht den richtigen Namen) Streams(?) haben.
Ja richtig, auch unter Windows gibt es Forks. Das weiß nur fast keiner.
Sie heißen dort "Alternate Data Streams (ADS)".
