Mac OS X meldet Verzeichnisgrößen nicht richtig?

Question 1

Die Unterschiede haben verschiedene Gründe: unterschiedliche Zählweisen, unterschiedliche Tools, Komprimierung und etwas, das wie ein Fehler aussieht.

Dererster Unterschiedin der Größe, die Sie sehen, scheint einFehler im Finder. Die vom Finder angezeigten Dateigrößen werden irgendwie in Echtzeit berechnet und in .DS_StoreDateien zwischengespeichert. Aus irgendeinem Grund berechnet der Finder beim Duplizieren einer großen Anwendung/eines großen Ordners deren Größe während des Kopiervorgangs und speichert die dann unvollständige Größe zwischen. Diese Größe wird dann in den Finder-Fenstern ausgegraut angezeigt, wobei grau bedeutetDer Finder weiß, dass sich der Inhalt seit der letzten Größenberechnung geändert hat, hat ihn aber noch nicht neu berechnet.

Die einzige Möglichkeit, die Größe richtig neu zu berechnen, besteht darin, die .DS_StoreDatei im Anwendungsordner zu löschen, dann den Finder zu beenden (beispielsweise über den Aktivitätsmonitor) und ihn erneut zu starten (über das Dock-Symbol). Wenn Sie die .DS_StoreDatei nicht löschen, bleibt sie weiterhin ausgegraut. Vielleicht warten Sieirgendwann(Stunden, Tage, Neustart, ...) veranlasst den Finder, dies selbstständig zu erledigen.

Danach sollten Sie sehen, dass alle vom Finder gemeldeten Größen gleich sind.

Also ja, es sieht nach einem Finder-Fehler aus, zumindest in OSX Lion (getestet mit 10.7.4 hier, Finder-Version 10.7.3). Sie können auch sehendieser Threaddie dasselbe Verhalten meldet.

Dann schauen wir uns das duTool an. Zuerst dachte ich, der Unterschied, den wir sehen, könnte durch den Unterschied zwischen logischer und physischer Größe der kopierten Elemente erklärt werden. Die logische Größe ist dierealGröße des Elements, also jedes einzelne darin enthaltene Informationsbit zusammengerechnet. Die physikalische Größe ist die Größe des Elements auf der Festplatte, wobei jedes Informationsbit in einen Festplattensektor geschrieben wird.

Beispielsweise hätte eine Datei, die ein einzelnes Zeichen enthält, eine logische Größe von 1 Byte, aber eine physische Größe von 512 Byte oder sogar 4096 Byte, wenn sie tatsächlich auf die Festplatte geschrieben wird. Die physische Größe ist normalerweise größer als die logische Größe (und hängt von der tatsächlichen Sektor-/Blockgröße der Festplatte oder des Dateisystems ab). Dies istin diesem anderen Thread ausführlicher erklärtDie logische Größe könnte größer sein im Falle vonSparse-Dateien, aber HFS+ scheint eine solche Funktion nicht zu unterstützen.

duzeigt nur die physische Größe an (und Sie können sagen, was eine BLOCKSIZE ist). Sie können sehen, dass die von gemeldete Größe duimmer größer (oder in Ausnahmefällen gleich) als das Original ist. Dies liegt an der Fragmentierung des Dateisystems und des Speicherplatzes. Wenn Sie eine Datei kopieren (in diesem Fall eigentlich eine Reihe von Dateien, da eine Anwendung ein Verzeichnis ist), werden neue Sektoren auf der Festplatte zugewiesen undwenn Fragmentierung auftrittist die Anzahl der verwendeten Blöcke normalerweise höher als die des Originalartikels. Manche Leute nennen dasDatei Slack.

Nun zurück zum Finder. Öffnen Sie denInformationen bekommenFenster der Anwendungen, die Sie dupliziert haben, sehen Sie, dass der Finder tatsächlich sowohl die logische als auch die physische Größe des ausgewählten Elements angibt. Das macht dann Sinn. Sie können sogar die vom Finder gemeldete physische Größe mit der von gemeldeten vergleichen, duwenn Sie ein wenig rechnen.

Warum rechnen? Weil der Finder die Dateigrößen in kB, MB oder GB anzeigt und dusie in kiB, MiB oder GiB meldet. Das sind dieIEC-Binärpräfixedie zum Berechnen und Anzeigen von Einheiten digitaler Informationen verwendet werden sollen.

Aber eigentlich bin ich nicht sicher, ob File Slack hier eine Rolle spielt, da liegt noch etwas anderes vor. HFS+-Volumes ermöglichen Komprimierung, erfolgt transparent, und Apple verwendet dies für die ursprünglichen Elemente, die vom Betriebssystem installiert wurden. Wenn Dateien dann mit Standardtools kopiert werden, wird die Komprimierung nicht mehr verwendet (standardmäßig, um abwärtskompatibel zu sein). Wenn Sie die Komprimierung für diese Dateien beibehalten möchten, müssen Sie den dittoBefehl anstelle von cpoder einer beliebigen Finder-Aktion verwenden. Dies istin dieser Rezension erklärt.

Hier ist die Ausgabe des Kopierens von iTunes.app mit den verschiedenen Techniken. Sie werden sehen, dass dito die Anwendung genau auf dieselbe Größe bringt und dabei die Komprimierung beibehält, was bei cpnicht der Fall ist. Und Sie können sogar die Binärdatei für den Arch entfernen, den Sie nicht benötigen, und dann die Gesamtgröße reduzieren):

antoine@amarante:/Applications$ du -ms iTunes.app/
281 iTunes.app/
antoine@amarante:/Applications$ cp -a iTunes.app/ iTunes-copy.app/
antoine@amarante:/Applications$ ditto iTunes.app/ iTunes-ditto.app
antoine@amarante:/Applications$ ditto --arch x86_64 iTunes.app/ iTunes-64.app
antoine@amarante:/Applications$ du -ms iTunes*
236 iTunes-64.app
289 iTunes-copy.app
281 iTunes-ditto.app
281 iTunes.app

Danke an @DanPritts für seine Antwortauf meinem ergänzenden Beitrag.

Answer