Mac OS X meldet die Verzeichnisgrößen nicht richtig?

Im Finder habe ich festgestellt, dass der Finder beim Duplizieren einiger .app-Dateien (im Anwendungsordner) anzeigt, dass die doppelte .app-Datei nicht dieselbe Größe wie das Original hat. Diese Diskrepanz in der Dateigröße tritt nicht bei allen von mir duplizierten .app-Dateien auf. Je größer die .app-Datei ist, desto wahrscheinlicher ist es jedoch, dass das Duplikat nicht dieselbe Größe wie das Original aufweist. Hier sind einige Beispiele:

GarageBand.app - 381.7 MB
GarageBand copy.app - 373.2 MB

iMovie.app - 695.3 MB
iMovie copy.app - 635.4 MB

Install Xcode.app - 1.81 GB
Install Xcode copy.app - 1.57 GB

Jetzt bin ich neu bei Macs und als ich dieses Problem mit der Dateigrößenabweichung bemerkte, stellte ich fest, dass .app-Dateien eigentlich keine Dateien sind - es sind wirklich Verzeichnisse, aber Finder zeigt sie an, als wären es Dateien. Daher dachte ich, dass der Duplizierungsprozess möglicherweise nicht den gesamten Inhalt des ursprünglichen .app-Verzeichnisses kopiert und dies den Unterschied in der "Dateigröße" erklärt. Aber dann habe ich DeltaWalker heruntergeladen und installiert, ein Tool zum Vergleichen von Dateien und Ordnern, und DeltaWalker sagte, dass die doppelten .app-Verzeichnisse genau die gleichen sind wie die ursprünglichen .app-Verzeichnisse. Der Kopiervorgang hat also einwandfrei funktioniert, und es scheint daher ein Problem mit der Größe der Finder-Berichtsdateien zu geben.

Ich habe auch die Größe der Verzeichnisse in Terminal mit dem Befehl "du" überprüft, und dies zeigt auch Unterschiede in der Größe zwischen dem ursprünglichen und dem doppelten Verzeichnis:

du -k /Applications/GarageBand.app/
212868  /Applications/GarageBand.app/

du -k /Applications/GarageBand\ copy.app/
397880  /Applications/GarageBand copy.app/

du -k /Applications/iMovie.app/
629644  /Applications/iMovie.app/

du -k /Applications/iMovie\ copy.app/
700500  /Applications/iMovie copy.app/

du -k /Applications/Install\ Xcode.app/
1771864 /Applications/Install Xcode.app/

du -k /Applications/Install\ Xcode\ copy.app/
1772228 /Applications/Install Xcode copy.app/

Außerdem handelt es sich nicht nur um .app-Verzeichnisse. Ich habe mein / Developer / Library-Verzeichnis dupliziert und Folgendes gesagt:

du -k /Developer/Library/
320784  /Developer/Library/

du -k /Developer/Library\ copy/
399868  /Developer/Library copy/

Kann jemand erklären, warum Mac OS X die Verzeichnisgrößen nicht korrekt angibt? Ist es ein Fehler (schwer zu glauben für etwas so Einfaches) oder fehlt mir etwas (ich bin ein neuer Mac-Benutzer)?

(Ich verwende Mac OS X Lion 10.7.2)

UPDATE als Antwort auf elofturtle:

Das Merkwürdigste daran ist, dass Finder keine Konsistenz aufweist. Ich habe gerade 2 Duplikate der GarageBand.app erstellt und dann 2 Duplikate von einem der Duplikate. Finder zeigt jedes Duplikat in einer anderen Größe an:

GarageBand.app - 381.7 MB
GarageBand copy.app - 357.6 MB (duplicate of GarageBand.app)
GarageBand copy 2.app - 353.9 MB (duplicate of GarageBand.app)
GarageBand copy 3.app - 378.2 MB (duplicate of GarageBand copy 2.app)
GarageBand copy 4.app - 329.1 MB (duplicate of GarageBand copy 2.app)

Beachten Sie auch, dass "GarageBand copy 3.app" größer als "GarageBand copy 2.app" ist, während "GarageBand copy 4.app" kleiner als "GarageBand copy 2.app" ist. Das muss ein Fehler im Finder sein.

Folgendes sagt "du-k" zu allen:

212868  /Applications/GarageBand.app/
397880  /Applications/GarageBand copy.app/
397880  /Applications/GarageBand copy 2.app/
397880  /Applications/GarageBand copy 3.app/
397880  /Applications/GarageBand copy 4.app/

Zumindest heißt es, dass alle Duplikate die gleiche Größe haben, aber nicht die gleiche Größe wie das Original.

Die Unterschiede sind auf verschiedene Gründe zurückzuführen: verschiedene Zählweisen, verschiedene Tools, Komprimierung und das, was wie ein Fehler aussieht.

Der erste Größenunterschied, den Sie sehen, scheint ein Fehler im Finder zu sein . Die vom Finder angezeigten Dateigrößen werden in Echtzeit berechnet und in .DS_StoreDateien zwischengespeichert . Aus irgendeinem Grund berechnet der Finder beim Duplizieren einer großen Anwendung / eines großen Ordners seine Größe während des Kopiervorgangs und speichert die dann unvollständige Größe im Cache. Daraufhin wird diese Größe in den Finder-Fenstern grau angezeigt. Dies bedeutet, dass der Finder weiß, dass sich der Inhalt seit der letzten Größenberechnung geändert hat, aber noch keine Neuberechnung vorgenommen hat .

Die einzige Möglichkeit, die Größe korrekt neu zu berechnen, besteht darin, die .DS_StoreDatei im Anwendungsordner zu löschen , den Finder zu beenden (z. B. über den Aktivitätsmonitor) und erneut zu starten (über das Dock-Symbol). Wenn Sie die .DS_StoreDatei nicht löschen , bleibt sie immer noch ausgegraut. Warten Sie einige Zeit (Stunden, Tage, Neustart, ...), bis der Finder dies selbst erledigt.

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

Also ja, es sieht aus wie ein Finder-Fehler, zumindest in OSX Lion (getestet mit 10.7.4 hier, Finder Version 10.7.3). Sie können auch diesen Thread sehen, der dasselbe Verhalten meldet.

Betrachten wir dann das duTool. Zuerst dachte ich, der Unterschied, den wir sehen, könnte durch den Unterschied zwischen der logischen und der physischen Größe der zu kopierenden Objekte erklärt werden. Die logische Größe ist die tatsächliche Größe des Elements, dh jedes einzelne Informationsbit, das es enthält, wird zusammenaddiert. Die physische Größe ist die Größe des Elements auf der Festplatte, wobei jedes Informationsbit auf einen Festplattensektor geschrieben wird.

Eine Datei, die ein einzelnes Zeichen enthält, hat beispielsweise eine logische Größe von 1 Byte, aber eine physikalische 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 wird in diesem anderen Thread ausführlicher erläutert . Die logische Größe könnte bei Dateien mit geringer Dichte größer sein , aber HFS + scheint eine solche Funktion nicht zu unterstützen.

duzeigt nur die physische Größe (und Sie können sagen, was eine BLOCKSIZE ist). Sie können sehen, dass das von angegebene Format duimmer größer (oder ausnahmsweise gleich) als das Original ist. Dies liegt an der Fragmentierung des Dateisystems und des Speicherplatzes. Wenn Sie eine Datei kopieren (hier tatsächlich eine Reihe von Dateien, da eine Anwendung ein Verzeichnis ist), werden neue Sektoren auf der Festplatte zugewiesen, und wenn eine Fragmentierung auftritt , ist die Anzahl der verwendeten Blöcke normalerweise höher als die des ursprünglichen Elements. Einige Leute nennen das File Slack .

Nun zurück zum Finder. Wenn Sie das Informationsfenster für die duplizierten Anwendungen öffnen , werden Sie feststellen, dass der Finder sowohl die logische als auch die physische Größe des ausgewählten Elements anzeigt. Was dann Sinn macht. Sie können sogar die vom Finder gemeldete physische Größe mit der von vergleichen, duwenn Sie ein bisschen rechnen.

Warum etwas Mathe machen? Denn der Finder zeigt die Dateigrößen in kB, MB oder GB an, wo dusie in kB , MiB oder GiB angezeigt werden. Dies sind die binären IEC-Präfixe, mit denen die Einheiten digitaler Informationen berechnet und angezeigt werden sollen.

Aber eigentlich bin ich mir nicht sicher, ob File Slack hier involviert ist, es gibt noch etwas anderes. HFS + -Volumes ermöglichen eine transparente Komprimierung , die Apple für die vom Betriebssystem installierten Originalelemente verwendet. Wenn Dateien mit Standardwerkzeugen kopiert werden, wird die Komprimierung nicht mehr verwendet (standardmäßig, um abwärtskompatibel zu sein). Wenn Sie die Komprimierung dieser Dateien beibehalten möchten, müssen Sie den dittoBefehl anstelle cpeiner Finder-Aktion verwenden. Dies wird in diesem Test erklärt .

Hier ist die Ausgabe des Kopierens von iTunes.app mit den verschiedenen Techniken. Sie werden feststellen, dass die Anwendung unter Beibehaltung der Komprimierung genau dieselbe Größe hat, wohingegen cpdies nicht der Fall ist. Und Sie können sogar die Binärdatei für den nicht benötigten Bogen entfernen und dann die gesamte Größe verkleinern.

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

Vielen Dank an @DanPritts für seine Antwort auf meinen ergänzenden Beitrag .

Dies ist ein furchtbarer Fehler in OS X. Sie können ihn am einfachsten feststellen, indem Sie ein großes Anwendungspaket duplizieren, dann den Inhalt anzeigen und eine große Datei von innen löschen. Der Speicherplatz wird nicht wiederhergestellt. Die Datei ist immer noch riesig. Wenn Sie beispielsweise ein Anwendungspaket mit 3,5 GB haben, den Inhalt anzeigen und dann 3 GB daraus entfernen, sollten Sie jetzt eine Anwendung mit einer Dateigröße von 500 MB haben. Du wirst nicht. Es wird immer noch 3,5 GB sein.

Dies ist im Grunde eine Vermutung, aber ich sehe zwei Möglichkeiten:

1. Einige Daten wurden gelöscht, aber im Original nicht freigegeben, und dies wird nicht kopiert. Es wird jedoch bei einigen Suchvorgängen zur Datenträgernutzung angezeigt, bei anderen jedoch nicht (unterschiedliche Parameter, die du oder OS X intern verwenden).
2. Einige Daten werden mit dem ursprünglichen Speicherort verknüpft. Dies wirkt sich auf die wahrgenommene Größe in verschiedenen Tools aus.

Wenn (1), sollten Sie wahrscheinlich unterschiedliche Ergebnisse erzielen, indem Sie eine dritte Kopie erstellen und die Kopien vergleichen.

Erstens müssen Sie sich bewusst sein, dass es sich bei Mac .app-Dateien tatsächlich um Verzeichnisse handelt , nicht um kompilierte Binärdateien wie Windows .exe-Dateien. Der Finder verbirgt diese Tatsache nur für Ordner mit dem Namen * .app.

zB (vom Terminal)

# cd /Applications/Calculator.app
# ls
Contents/

Ich bin mir ziemlich sicher, dass Finder / Get Info eine nicht sehr clevere Heuristik verwendet, um die Größe des Ordners .app zu berechnen. Dies bedeutet, dass nicht jeder einzelne Unterordner und jede einzelne Datei aufgelistet und alle diese Größen addiert werden müssen.

Ich vermute, dass die Schätzung auf der Kopie korrekt ist, da OSX vor kurzem jede Datei darin untersuchen musste, als Sie die Kopie erstellt haben, während OSX dies auf dem Original möglicherweise nie getan hat (z. B. bei einer Werksinstallation).

Ich hatte dieses Problem mit meinem Home Directory, nachdem ich es nach der Installation von Yosemite auf der SSD auf eine interne Festplatte verschoben hatte. Bei Verwendung von "Get Info" wurde eine falsche Größe von nur 8 GB gemeldet, obwohl in der Statusleiste von Finder die korrekte Größe von 240 GB angezeigt wurde. Ich habe das Problem behoben, indem ich im Ordner "Benutzer" auf "Informationen" geklickt habe. Dieser berechnete dann ordnungsgemäß und korrigierte die vom Basisverzeichnis gemeldete falsche Größe.