mac:xattr

HFS+ und die erweiterten Attribute

Unter Datei-Attribute versteht man idR Informationen, die zu einer Datei oder einem Verzeichnis gehören, diese aber nicht direkt in der Datei abgespeichert werden. Andere Begriffe für Datei-Attribute sind zB Datei-Metadaten oder Datei-Eigenschaften. Nahezu jedes Betriebssystem kennt, abhängig vom verwendeten Dateisystem, unterschiedliche Datei-Attribute.

Resource Forks und Extended Attributes

Historisch betrachtet ist Apple schon seit den Classic Mac OS (≤ 9.2) Systemen einen eigenen Weg gegangen und hat Daten auf Apples Filesystemen in mehreren Teilen abgelegt → Das Data- und Resource Fork¹⁾. Das Data Fork enthält den Hauptbestandteil der Datei, während das Resource Fork die Datei Metadaten wie zB Icons, Versionsangaben bzw. FinderInfo Daten wie zB Filetype, Creator beinhaltet. Dadurch ist es zB möglich, Daten ohne Suffix (Dateiendung zB .jpg) in einer bestimmten Anwendung zu öffnen. Manchmal wurde sogar der eigentliche Hauptbestandteil einer Datei in der Resource Fork abgelegt, wie zB bei PostScript Schriften.

Mit Einführung von Mac OSX trat die Resource Fork etwas in den Hintergrund. Das Apple Filesystem HFS+²⁾ hatte das Feature der erweiterten Attribute (EAs) bereits schon 1998 implementiert, sie wurden aber erst mit Tiger (10.4) zum Leben erweckt. Eine Vielzahl von EAs bereichert fortan das Leben einer Data Fork. Mit dem Attribut com.apple.quarantine werden User nun darauf aufmerksam gemacht, dass eine Datei aus dem Internet geladen wurde und möglicherweise gefährlich sein könnte, durch das Attribut com.apple.diskimages.recentcksum wird die Integrität eines DMG Files gesichert, manche Text Editoren wie zB TextEdit speichern Informationen bzgl. des Encodings in com.apple.TextEncoding ab usw. Alte Bekannte wie Finder-Info wurden in com.apple.FinderInfo gepackt und bevor sich nun der Mantel des Schweigens gänzlich über die Recource Fork legte, kam Snow Leopard und die scheinbar in der Versenkung zu verschwindende Resource Fork rettete sich in com.apple.ResourceFork. Wobei die beiden letztgenannten keine echten EAs sind.

Cross Plattform Handling

Weder die früheren Resource Forks hatten, noch die modernen EAs haben ein leichtes Leben, wenn das Apple Mac System über den Tellerrand nach anderen Plattformen schielt. In heterogenen Netzwerken ist die Koexistenz von Mac OS(X) und anderen Plattformen wie zB Windows oder Linux nicht unproblematisch. Unterschiedliche Plattformen arbeiten auf unterschiedlichen Filesystemen (HFS+, NTFS, FAT, ext3 usw) mit unterschiedlichen Netzwerkprotokollen (AFP, SMB/CIFS) und die haben gegeseitig von den Features des anderen Filesysytems im Prinzip keine Ahnung. Microsoft öffnete sich jedoch mit NTFSv3.1³⁾ und somit der Einführung der Alternative Data Streams (ADS), als Equivalent zu den Apple Metadaten, nun der Apple Metadaten Technologie und stellte mit den SFM Dienst (Services For Macintosh) nun eine AFP Implementierung bereit, die es Mac OS Clients erlaubte einen Windows Server als Fileserver zu benutzen. Seit Snow Leopard prüft der Mac Client ob der angeschlossene SMB Server Data Streams unterstützt und die Apple Metadaten werden fortan bei ≥ NTFSv3.1 basierten Systemen in den ADS gespeichert.

Da Microsoft die Services for Macintosh jedoch nicht weiterentwickelte, implementierte Apple ab Mac OSX (≥ 10.1) einen eigenen SMB Client. Von nun an konnte man einen Windows Fileserver auch ohne SFM zur Zusammenarbeit mit Mac Clients überreden. Mit Mac OS 10.2 ging Apple sogar noch einen Schritt weiter und implementierte einen SMB Server in das Betriebssystem, so dass ein Mac Client auch Fileserver für Windows PCs sein konnte.

Diese Metadaten werden nun für den Benutzer unsichtbar im Filesystem abgelegt aber Mac OSX bringt out of the box bereits Tools mit, welche die vorhandenen EAs anzeigt, Windows User müssen auf ThirdParty Tools wie streams von Sysinternals⁴⁾ zurückgreifen, erst ab Windows Vista bringt auch Windows eine modifizierte Version des dir-Befehls mit, mit welchem man sich die ADS anzeigen zu lassen (dir /r).

Die EAs einer Datei auf einem am Mac gemounteten NTFS Filesystem (smbfs) lassen sich zB mit xattr oder ls -l@ anzeigen:

$ xattr MacFile.dmg  
com.apple.diskimages.fsck
com.apple.diskimages.recentcksum

Auf einem Windows Computer mit NTFS Filesystem zeigt sich ein ähnliches Bild, wenn die Datei von einem Mac System ≥ 10.6 abgespeichert wurde:

C:\orgfiles\MacData>streams MacFile.dmg  
Streams v1.56 - Enumerate alternate NTFS data streams
Copyright (C) 1999-2007 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\orgfiles\MacData\MacFile.dmg:
:com.apple.diskimages.fsck:$DATA	20
:com.apple.diskimages.recentcksum:$DATA	80

AppleDoubles

Aber »fremde« Dateisysteme sind nicht immer so kooperativ wie es NTFSv3.1 ist, zumindest dann, wenn es von Snow Leopard bedient wird. Während Microsoft die Metadaten eher zweitrangig betrachtete, waren sie für Apple immer schon ein wichtiger Bestandteil. Ohne diese Meta-Informationen ist ein Apple System nicht vernünftig zu betreiben. Apple musste sich nun etwas einfallen lassen, wie man diese Meta-Informationen auf Dateisysteme transportiert, welche keinen nativen, bzw. Apple kompatiblen, Metadaten Support haben. Einer der prominentesten Vertreter dieser Gattung ist das Windows FAT Dateisystem⁵⁾. Es findet nicht nur in (alten) Windows Systemen Verwendung, sondern es ist das Standardsystem auf zahlreichen Wechseldatenträgern wie zB USB-Sticks, CF- bzw. SD-Karten und aus Kompatibilitäsgründen auch auf vielen externen Festplatten. Aber auch alle Standard UNIX Dateisysteme wie zB ext3 bieten keinen nativen Apple Metadaten Support.

Apple entwickelte nun das AppleDouble⁶⁾ Format um die Metadaten auf »fremde« bzw. HFS+ inkompatible Dateisysteme zu transportieren. Wie man dem Namen schon entnehmen kann, verwendet das AppleDouble Format zwei Dateien: Die eigentliche Data Fork (die Datei als solches) und eine weitere Datei, welche die Metadaten und die Resource Fork Informationen beinhaltet. Diese zweite Datei wird wegen seinem Prefix ._ »dot-underbar« File genannt. Käme diese Datei abhanden, verliert man uA zB die Verknüpfung zwischen der Datei und der erzeugenden Applikation, was vor allem bei Dateien ohne Suffix (Dateiendung) für Verwirrung sorgt. Aber auch bei Dateien die aus einer bekannten Applikation wie zB Quark Express stammen, verliert man die Information mit welcher Version von QXP diese Datei erstellt wurde.

Diese (Zwangs-) Trennung von Data Fork und Metadaten in zwei seperate Dateien hat einen gravierenden Nachteil. Erstens sind sie für den Benutzer des Zielsystems sichtbar, wenn er sich auf einem Windows System die versteckten Dateien anzeigen lässt (was viele User tun) oder auf einem UNIX System man sich mit ls -la den Inhalt inkl. der ansonst verborgenen Dot-Files eines Verzeichnisses anzeigen lässt (was auch viele User tun). In beiden Fällen kann es vorkommen, dass der Benutzer nicht weis, warum und wieso diese versteckten Dateien auf seinen Rechner kommen und ggf. diese löscht. Zweitens werden durch die Unkenntnis des zugrunde liegenden Dateisystems die sprichwörtlichen Zusammenhänge dieser Dateien, welche ja erst mal zu dieser Notlösung geführt haben, die Dateischwester ._ beim Verschieben der eigentlichen Datei (Data Fork) nicht berücksichtig und trennt diese, was auf der einen Seite eine möglicherweise beschädigte, mindestens aber eine gehandicapte Datei und auf der anderen Seite eine völlig nutzlose AppleDouble Datei zurück lässt.

Lässt man sich nun den Inhalt eines solchen, im Falle von FAT als msdos, gemounteten Volumes anzeigen, fällt auf, dass die in der AppleDouble Datei gespeicherten Information von Mac OS bereits wieder als EAs der Data Fork angezeigt werden:

pronto-macpro:MacFilesFAT pronto$ ls -la@  
total 3856
drwxrwxrwx  1 pronto  staff     4096 13 Mai 20:36 .
drwxrwxrwx  1 pronto  staff     4096 13 Mai 20:36 ..
-rwxrwxrwx  1 pronto  staff     4096 13 Mai 20:36 ._MacFile.dmg
-rwxrwxrwx@ 1 pronto  staff  1961028 25 Apr 18:55 MacFile.dmg
 com.apple.diskimages.fsck	     20 
 com.apple.diskimages.recentcksum	     80

Löscht man nun die AppleDouble Datei, kann auch Mac OS keine weiteren Metadaten mehr erkennen. Selbes geschieht wenn durch unachtsames Verschieben der Data Fork diese von der AppleDouble Datei getrennt wird:

$ rm ._MacFile.dmg  
$ ls -la@  
total 3848
drwxrwxrwx  1 pronto  staff     4096 13 Mai 21:17 .
drwxrwxrwx  1 pronto  staff     4096 13 Mai 21:11 ..
-rwxrwxrwx  1 pronto  staff  1961028 25 Apr 18:55 MacFile.dmg

Diese AppleDouble Dateien haben noch einen weiteren gravierenden Nachteil: Sie nisten sich auch auf Dateisystemen ein, wo man sie so gar nicht haben möchte. Wird zB auf einem Mac System eine CD oder DVD gebrannt, haben wir es bei dem Ziel Dateisystem (ISO 9660⁷⁾) wieder mit so einem Dateisystem zu tun, welches mit Apples Metadaten nichts anfangen kann. Anders als bei Windows Alternative Data Streams, welche beim Brennen der CD einfach weggelassen werden, kommt bei Apple wieder der ganze AppleDouble Sumsebrums auf die CD. Nicht schön wenn zB im Printbereich, wo Apple immer noch der Platzhirsch ist, ein CD-Master für eine CD Heftbeilage gebrannt wird. Fieserweise bemerkt das der Benutzer an seiner Mac OSX Workstation gar nicht, weil mit einem Punkt beginnende Dateien vom Finder standardmäßig gar nicht angezeigt werden. Somit wird der Segen zum Fluch … Was zumindestens bei uns schon mal zu einer Kundenreklamation geführt hat und wir fast 1.500 Heftbeilagen CDs wegschmeissen konnten. Der Kunde zeigte sich gnädig und wir uns geläutert.

So einfach es Apple dem Benutzer gemacht hat seine Arbeitsgewohnheiten und den dadurch resultierenden Komfort beizubehalten, so schwer haben sie es ihm gemacht, auf dieses Feature, wenn auch nur temporär, zu verzichten. Der Artikel -> CD ohne Metadaten erstellen beschreibt eine Möglichkeit sich dieser Dinge zB auf einer CD zu entledigen.

Aufbau der erweiterten Attribute

Erweiterte Attribute (EAs) erweitern die Basis Attribute zu Dateien oder Verzeichnissen im Dateisystem (HFS+). Sie werden in einem name:value Paar gespeichert, welche mit dem Data Fork Objekt im Dateisystem verknüpft sind. Der Name (Identifier → name) eines erweiterten Attributs ist ein simpler UTF-8 String, welcher idR den Urheber des Attributs identifiziert (com.apple) und ggf noch die Funktion beschreibt (quarantine). Im Prinzip aber ist der Name frei wählbar. Der Wert (value) eines Attributs ist ein Pointer zu einem Datenpuffer im Dateisystem, welcher Text oder Binärdaten mit dem Attribut verknüpft.

Mac OS bringt einige Tools mit, mit denen die erweiterten Attribute angezeigt, bearbeitet oder gelöscht werden können. xattr dürfte das mächtigste sein aber auch einige Optionen zum ls-Befehl können gute Dienste leisten. Ein erstes Indiz für das Vorhandensein eines EA ist ein @-Zeichen bei der Ausgabe von ls -l:

$ ls -l  
total 17488
-rw-r--r--@ 1 pronto  staff   209428 14 Mai 14:19 Bilder
-rw-r--r--@ 1 pronto  staff   128064 14 Mai 14:21 ECI_Offset_2009_EN.pdf
-rw-r--r--@ 1 pronto  staff   140408 14 Mai 14:21 Filme
-rw-r--r--@ 1 pronto  staff   285397 14 Mai 14:21 Logo_Klar.psd
-rwxr-xr-x@ 1 pronto  staff   261469 14 Mai 14:21 SC_paper_info.pdf
-rw-r--r--@ 1 pronto  staff  1131770 14 Mai 14:21 Trapping.ai
-rw-r--r--@ 1 pronto  staff  5919242 14 Mai 14:20 Ukelele_1.8.4.dmg

Nun gibt es zwei Möglichkeiten sich die erweiterten Attribute anzeigen zu lassen. Sowohl das ls-Kommando wie auch das xattr-Kommando bieten eine Möglichkeit. Um sich einen Überblick zu verschaffen eignet sich das ls-Kommando mit den Optionen -l@ erstmal besser:

$ ls -l@  
total 16576
-rw-r--r--@ 1 pronto  staff   209428 14 Mai 14:19 Bilder
 com.apple.FinderInfo	     32 
 com.apple.ResourceFork	 209091 
-rw-r--r--@ 1 pronto  staff   128064 14 Mai 14:21 ECI_Offset_2009_EN.pdf
 com.apple.FinderInfo	     32 
 com.apple.quarantine	     42 
-rw-r--r--@ 1 pronto  staff   140408 14 Mai 14:21 Filme
 com.apple.FinderInfo	     32 
 com.apple.ResourceFork	 140072 
-rw-r--r--@ 1 pronto  staff   285397 14 Mai 14:21 Logo_Klar.psd
 com.apple.FinderInfo	     32 
 com.apple.ResourceFork	  29090 
-rwxr-xr-x@ 1 pronto  staff   261469 14 Mai 14:21 SC_paper_info.pdf
 com.apple.FinderInfo	     32 
 com.apple.quarantine	     42 
-rw-r--r--@ 1 pronto  staff  1131770 14 Mai 14:21 Trapping.ai
 com.apple.FinderInfo	     32 
 com.apple.ResourceFork	    368 
-rw-r--r--@ 1 pronto  staff  5919242 14 Mai 14:20 Ukelele_1.8.4.dmg
 com.apple.diskimages.recentcksum	     79

ls -l@ Dateiname zeigt nun Details zu den EAs einer Datei an:

$ ls -l@ rezilla1.png  
-rw-r--r--@ 1 pronto  staff  39890 14 Mai 17:02 rezilla1.png
 com.apple.metadata:kMDItemIsScreenCapture	   42 
 com.apple.metadata:kMDItemScreenCaptureType	   48

Hier wird die Namens Konvention name:value verdeutlicht. Das EA com.apple.metadata hat hier den Wert kMDItemIsScreenCapture bzw. kMDItemScreenCaptureType. Der Inhalt des EAs wird vom Betriebsystem oder einer Anwendung ausgewertet, dadurch werden zT Anzeigeoptionen eingestellt, Abfragen ausgelöst, Checksummen ausgewertet usw. Im Prinzip kann eine Datei, bzw. in diesem Kontext das Data Fork, auch ohne diese EAs ganz gut leben, dabei ist es umso mehr verwunderlich, dass die Anzahl der EAs nun fast schon täglich anwächst.

Diese Frage beantwortet Apple mit ein paar genialen Tricks. Apple wirbt mit den geringen Platzverbrauch und der überragenden Performance von Snow Leopard und das wird nicht nur dadurch erreicht, dass Snow Leopard keinen PPC Support mehr in den Executables bereitstellt, wie das noch bei Leopard der Fall war und was natürlich Platz kostet, sondern auch dadurch, dass in Snow Leopard die Executables komprimiert und rafiniert im Dateisystem versteckt werden. Wie John Siracusa in seinem äusserts amüsanten Blog Beitrag über die Apple Tricks in Snow Leopard⁸⁾ erläutert, packt Apple die komprimierten Executabels zu Hauf in die altehrwürdigen ResourceForks. Warum in die ResourceFork? Nun Apple möchte vermeiden, dass ältere Systeme, welche erstmal nichts mit diesen HFS+ komprimierten Dateien anfangen können, diese Daten nun versehentlich in irgendeiner Weise zerstören können. Apple hat sich daraufhin entschlossen die komprimierten Daten in einer Art und Weise zu verstecken, die auch von älteren Systemen verstanden wird → Der ResourceFork.

Die ResouceFork aber ist nicht der einzige Platz in die Apple in Snow Leopard Dateien schmuggelt. Das HFS+ Filesystem reserviert für jede Datei einen gewissen Teil für die erweiterten Attribute. Typischerweise ist das ein Cluster, also 4KB. 4KB aber sind eine Menge, für ein paar Byte, die von einem erweiterten Attribut belegt werden. Apple geht jetzt her und packt kleine Dateien, komprimiert oder unkomprimiert in die erweiterten Attribute und nutzt so den Platz, der ansonsten verloren wäre.

Der Performancezuwachs von Snow Leopard lässt sich ebenfalls durch das Komprimieren der Dateien erklären. In modernen PC Systemen hat die CPU Performance überproportional zur Festplattenperformance zugenommen. Werden die Daten nun komprimiert übetragen, ist der Performancegewinn durch das Übertragen einer geringeren Datenmenge höher zu bewerten als die Perfomanceeinbuße einer modernen CPU beim Dekomprimieren der Daten. Apple hat somit zwei Fliegen mit einer Klatsche geschlagen → Platz gespart und Performance gewonnen. Hut ab.

— pronto 2010/05/13 22:31

¹⁾ http://en.wikipedia.org/wiki/Resource_fork

²⁾ http://en.wikipedia.org/wiki/HFS_Plus

³⁾ http://en.wikipedia.org/wiki/NTFS

⁴⁾ http://technet.microsoft.com/en-us/sysinternals/bb897440.aspx

⁵⁾ http://en.wikipedia.org/wiki/File_Allocation_Table

⁶⁾ http://en.wikipedia.org/wiki/Appledouble

⁷⁾ http://de.wikipedia.org/wiki/ISO_9660

⁸⁾ http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/3