Mac OS X ne rapporte pas correctement la taille des répertoires?

Dans le Finder, j'ai remarqué que si je duplique certains fichiers .app (dans le dossier Applications), le Finder montrera que le fichier .app en double n'est pas de la même taille que l'original. Cette différence de taille de fichier ne se produit pas pour tous les fichiers .app que je duplique, mais il semble que plus le fichier .app est volumineux, plus le doublon n'affichera probablement pas la même taille que l'original. Voici quelques exemples:

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

Maintenant que je suis nouveau sur Mac, et après avoir remarqué ce problème de différence de taille de fichier, j'ai découvert que les fichiers .app ne sont en fait pas des fichiers - ce sont vraiment des répertoires, mais le Finder les affiche comme s'ils étaient des fichiers. J'ai donc pensé que le processus de duplication n'avait peut-être pas copié tout le contenu du répertoire .app d'origine et cela expliquait la différence de "taille de fichier". Mais j'ai ensuite téléchargé et installé DeltaWalker, qui est un outil de comparaison de fichiers / dossiers, et DeltaWalker a déclaré que les répertoires .app en double étaient exactement les mêmes que les répertoires .app d'origine. Le processus de duplication a donc parfaitement fonctionné et il semble donc qu'il y ait un problème avec la taille des fichiers de rapports du Finder.

J'ai également vérifié les tailles des répertoires dans Terminal, à l'aide de la commande "du", et cela montre également des différences de taille entre les répertoires d'origine et en double:

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/

De plus, ce ne sont pas seulement les répertoires .app. J'ai dupliqué mon répertoire / Developer / Library, et voici ce que du a dit:

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

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

Quelqu'un peut-il donc expliquer pourquoi Mac OS X ne semble pas signaler correctement la taille des répertoires? Est-ce un bug (difficile à croire pour quelque chose d'aussi simple), ou est-ce que je manque quelque chose (étant un nouvel utilisateur Mac)?

(J'utilise Mac OS X Lion 10.7.2)

MISE À JOUR en réponse à elofturtle:

Ce qui est le plus étrange, c'est que le Finder n'a aucune cohérence. Je viens de faire 2 doublons de GarageBand.app, puis j'ai fait 2 doublons de l'un des doublons. Le Finder affiche chaque double avec une taille différente:

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)

Notez également que "GarageBand copy 3.app" est plus grand que "GarageBand copy 2.app", tandis que "GarageBand copy 4.app" est plus petit que "GarageBand copy 2.app". Cela doit être un bug dans le Finder.

Voici ce que "du -k" dit à propos de chacun d'eux:

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/

Au moins, il indique que tous les doublons sont de la même taille, mais ils ne sont pas de la même taille que l'original.

Les différences provenaient de différentes raisons: différentes façons de compter, différents outils, compression et ce qui ressemble à un bug.

La première différence de taille que vous voyez semble être un bug dans le Finder . Les tailles de fichiers affichées par le Finder sont en quelque sorte calculées en temps réel et mises en cache dans les .DS_Storefichiers. Pour une raison quelconque, lors de la duplication d'une grande application / dossier, le Finder calcule sa taille pendant le processus de copie et met en cache la taille, puis incomplète. Il indique ensuite que la taille est grisée dans les fenêtres du Finder, grise signifiant que le Finder sait que le contenu a changé depuis son dernier calcul de taille mais qu'il ne l'a pas encore recalculé .

Le seul moyen que j'ai trouvé pour le faire recalculer correctement la taille est de supprimer le .DS_Storefichier dans le dossier Application, puis de quitter le Finder (à partir du moniteur d'activité par exemple) et de le relancer à nouveau (à partir de l'icône du Dock). Si vous ne supprimez pas le .DS_Storefichier, il reste grisé. Peut-être qu'attendre un certain temps (heures, jours, redémarrage, ...) fera que le Finder le fera tout seul.

Après cela, vous devriez voir que toutes les tailles signalées par le Finder sont les mêmes.

Alors oui, cela ressemble à un bug du Finder, au moins dans OSX Lion (testé avec 10.7.4 ici, Finder version 10.7.3). Vous pouvez également voir ce fil qui rapporte le même type de comportement.

Considérons ensuite l' duoutil. Au début, je pensais que la différence que nous voyons pourrait s'expliquer par la différence entre les tailles logiques et physiques des éléments copiés. La taille logique est la taille réelle de l'élément, ce qui signifie que chaque bit d'information qu'il contient est additionné. La taille physique est la taille de l'élément sur le disque, où chaque bit d'information est écrit sur un secteur de disque.

Par exemple, un fichier contenant un seul caractère finirait par avoir une taille logique de 1 octet, mais une taille physique de 512 octets ou même 4096 octets lorsqu'il est réellement écrit sur le disque. La taille physique est généralement supérieure à la taille logique (et dépend de la taille réelle du secteur / bloc du disque ou du système de fichiers). Ceci est expliqué plus en détail dans cet autre fil . La taille logique pourrait être plus grande dans le cas de fichiers épars , mais HFS + ne semble pas prendre en charge une telle fonctionnalité.

duaffiche uniquement la taille physique (et vous pouvez lui dire ce qu'est un BLOCKSIZE). Vous pouvez voir que la taille indiquée par duest toujours plus grande (ou, exceptionnellement, la même) que l'original. Cela est dû à la fragmentation du système de fichiers et de l'espace disque. Lorsque vous copiez sur un fichier (en fait ici un tas de fichiers, car une application est un répertoire), de nouveaux secteurs sont alloués sur le disque et, à mesure que la fragmentation se produit , le nombre de blocs utilisés est généralement supérieur à celui de l'élément d'origine. Certaines personnes appellent ça File Slack .

Maintenant, revenons au Finder. Si vous ouvrez la fenêtre d' informations sur les applications que vous avez dupliquées, vous verrez que le Finder signale en fait à la fois la taille logique et physique de l'élément que vous avez sélectionné. Ce qui a alors du sens. Vous pourrez même comparer la taille physique rapportée par le Finder et celle rapportée par dusi vous faites un peu de calcul.

Pourquoi faire des maths? Parce que le Finder affiche les tailles de fichiers en ko, Mo ou Go où les duindique en kiB, MiB ou GiB. Ce sont les préfixes binaires CEI qui doivent être utilisés pour calculer et afficher les unités d'informations numériques.

Mais, en fait, je ne suis pas sûr que File Slack soit impliqué ici, il y a autre chose. Les volumes HFS + permettent la compression , de manière transparente, et Apple l'utilise pour les éléments d'origine installés par le système d'exploitation. Ensuite, lorsque les fichiers sont copiés à l'aide d'outils standard, la compression n'est plus utilisée (par défaut, pour être rétrocompatible). Si vous souhaitez conserver la compression sur ces fichiers, vous devez utiliser la dittocommande au lieu de cpou toute action du Finder. Ceci est expliqué dans cette revue .

Voici la sortie de la copie d'iTunes.app en utilisant les différentes techniques. Vous verrez que idem rend l'application exactement de la même taille, préservant la compression, où cppas. Et vous pouvez même supprimer le binaire de l'arche dont vous n'avez pas besoin, puis réduire toute la taille):

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

Merci à @DanPritts pour sa réponse sur mon post complémentaire .

C'est une faille / bogue horrible sous OS X. La façon la plus simple de le voir est de dupliquer un grand ensemble d'applications, puis d'afficher le contenu et de supprimer un énorme fichier de l'intérieur. L'espace ne récupérera pas. Le fichier est toujours énorme. Par exemple, si vous disposez d'un ensemble d'applications de 3,5 Go, vous affichez le contenu, puis supprimez 3 Go de celui-ci, vous devriez maintenant avoir une application avec la taille de fichier de 500 Mo. Tu ne vas pas. Ce sera toujours 3,5 Go.

C'est essentiellement une supposition, mais je vois deux possibilités:

1. Certaines données ont été supprimées mais non désallouées dans l'original, et cela n'est pas copié. Pourtant, il apparaît dans certaines recherches d'utilisation du disque, mais pas dans d'autres (différents paramètres donnés à du ou à toute utilisation d'OS X en interne).
2. Certaines données sont liées à l'emplacement d'origine, ce qui affecte la taille perçue dans différents outils.

Si (1) vous devriez probablement obtenir des résultats différents en faisant une troisième copie et en comparant les copies.

Tout d'abord, vous devez être conscient que les fichiers Mac .app sont en fait des répertoires , pas des binaires compilés comme les fichiers Windows .exe. Le Finder vous cache simplement ce fait pour les dossiers appelés * .app.

par exemple (depuis le terminal)

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

Je suis sûr que ce qui se passe est que Finder / Get Info utilise une heuristique pas très intelligente pour calculer la taille du dossier .app. Cela signifie qu'il n'a pas besoin d'énumérer chaque sous-dossier et fichier et d'ajouter toutes ces tailles.

Je suppose que l'estimation sur la copie est correcte car OSX a récemment dû inspecter chaque fichier qu'il contenait lorsque vous avez fait la copie, tandis que sur l'original, OSX n'a ​​peut-être jamais dû le faire (par exemple avec les installations d'usine)

J'ai eu ce problème avec mon répertoire personnel une fois que je l'ai déplacé sur un disque dur interne après avoir installé Yosemite sur le SSD. Lors de l'utilisation de `` Get Info '', il a signalé une taille incorrecte de seulement 8 Go, bien qu'il affiche la taille correcte de 240 Go dans la barre d'état du Finder. Je l'ai corrigé en cliquant sur Obtenir des informations dans le dossier Utilisateurs, qui a ensuite calculé correctement et corrigé la taille incorrecte signalée par le répertoire de base.