Mac-Praxis: Der Finder lügt – Dateigrößen exakt herausfinden
Speicherplatz auf einem Mac ist begrenzt und teuer – Apple verlangt hohe Preise für größere SSDs, und ein nachträgliches Upgrade ist bei den meisten Modellen unmöglich. Umso wichtiger ist es, dass man als Anwender stets im Bilde ist, welche Dateien wie viel Platz belegen. In der macOS-Dateiverwaltung „Finder“ stellt der Befehl „Ablage → Informationen“ (
+I) die erste Anlaufstelle. Dieses Fenster zeigt zwei unterschiedliche Zahlen an. Was diese beiden Werte bedeuten und warum sie oftmals nur die halbe Wahrheit sind, erklärt Howard Oakley in einem Blog-Beitrag zu
Dateigrößen unter macOS.
Dafür geht er zurück zu den Anfängen von Apple: Vor dem Mac wurden Dateigrößen lediglich von Blockgrößen verfälscht. Ein Dokument konnte stets nur Größen auf einem Speichermedium einnehmen, welches einem Vielfachen der festgelegten Blockgröße entsprach. Dies spiegelt sich bis heute im Info-Fenster wider: Die Größe in Klammern ist die auf Speicherblöcke aufgerundete Dateigröße. Mit dem Mac-System (später Mac OS Classic) führte Apple eine Zweiteilung ein, die für jede Datei galt: Neben dem Datenanteil (Data Fork) umfasste jede Datei zusätzlich einen Metadatenanteil (Resource Fork). Letztere konnte viel Platz einnehmen, etwa durch ein individuelles Icon und ähnliche Zusatzinformationen. Programme wie ResEdit zeigten den Platzbedarf beider Anteile. Zusätzlich speicherte Mac OS weitere systemspezifische Informationen zu jeder Datei; diese bleiben "unsichtbar" und zählen nicht zur Datei.
HFS+ und APFS: Schluss mit Resource Fork – eigentlichMit der Einführung von Mac OS X und den damit einhergehenden Änderungen am Dateisystem verabschiedete sich Apple von der Resource Fork. Stattdessen wurden Medien und Metadaten in einer Ordnerstruktur gesammelt. Als Bundle zusammengefasst, erscheinen sie im Finder wie eine Datei. Somit sollte die Größenangabe präziser sein. Doch zeigt Howard Oakley auf, dass auch im aktuellen macOS noch Unwägbarkeiten schlummern – eventuell sogar noch mehr als bisher. Der Grund sind "erweiterte Attribute" (xattr). Ein extremes Beispiel: Oakley konnte eine Textdatei mit einer im Finder angegebenen Größe von 391 Bytes erzeugen, der 90.000 Byte an erweiterten Attributen zugeordnet sind.
Details mit SpezialsoftwareEs stellt sich heraus, dass inzwischen das Gegenteil erreicht wurde, was das Ziel der Abschaffung der Resource Fork war. Inzwischen gibt es für jede Datei bis zu vier Komponenten, welche Platz kosten. Neben dem eigentlichen Inhalt speichert macOS dateisystemspezifische Eigenschaften, kleinere xattr-Anteile (bis zu 3804 Byte) sowie große xattr-Bereiche. Oakleys dedizierte Dateisystem-Apps
xattred sowie
Precize listen die gesammelten Bestandteile nebst Größe auf. Dabei stellt sich heraus, dass bei der Größenberechnung des Finders einige Attribute ausgeklammert bleiben.
Was der Finder als Dateigröße angibt, spiegelt nicht zwangsläufig die Gesamtheit aller zu einem Dokument gerechneten Informationen wider. (v.l.n.r.: Finder, Precize, xattred)
Ressource Fork (und andere) zählen nichtVerwendet eine Datei ein individuelles Icon in Form eines erweiterten Attributes vom Typ com.apple.ResourceFork, bleibt bei der Größenberechnung ausgeklammert, fand Oakley heraus; Ähnliches gilt für neuere Attributtypen wie com.apple.quarantine oder com.apple.macl. Andere wiederum inkludieren macOS bei der Größenberechnung. Somit kann man sich auf die Größenangabe des Finders nicht hundertprozentig verlassen. Oakley zeigt sich verwundert, insbesondere darüber, dass erweiterte Attribute vom Typ Resource Fork weiterhin in macOS herumspuken – über zwanzig Jahre nach Abkündigung. Wer genau wissen will, wie groß eine Datei ist (und warum), kommt um eine Metadatenanalyse mit Spezialsoftware nicht herum.