Différence de calcul de la taille du répertoire

J'ai besoin d'obtenir la taille du répertoire dans le terminal à des fins de signature. J'utilise la commande suivante:

du -s /path/to/dir

Je multiplie le résultat par la taille de bloc UNIX traditionnelle (512 octets) et j'obtiens la taille réelle du répertoire en octets. Cependant, la fenêtre de dialogue "Get Info" du Finder affiche la taille légèrement inférieure à celle calculée avec la commande de terminal. Et il semble qu'il soit reproductible sur n'importe quel dossier / bundle. Qu'est-ce que je rate?

Affiche normalement dudes informations sur l'utilisation du disque (d'où vient son nom). Garde en tête que

disk usage != sum of file sizes

Parce que chaque fichier occupe un certain nombre de blocs sur le système de fichiers (voir man mkfs.ext2par exemple). Cela signifie que dans une situation très rare, l'utilisation du disque d'un fichier est égale à sa taille réelle - pour cela, la taille doit être exactement un multiple de la taille du bloc.

Considérez les blocs de système de fichiers comme des boîtes qui contiennent des parties de fichiers - chacun peut contenir une partie d'un seul fichier.

Pour la version GNU de du, consultez l' --apparent-sizeoption.

Une situation encore plus intéressante peut se produire, lorsqu'il y a quelques fichiers épars sur le système de fichiers!

À propos de Mac OS X et du Finder (dans Snow Leopard, version 10.6.8), j'ai remarqué ce qui suit.

• J'obtiens le nombre d'octets pour les chiffres «quantifiés» du Finder d'un chemin (fichier ou dossier) avec le code (en bash(1)) ci-dessous.
  
• Les fenêtres et le volet "Info" du Finder affichent les chiffres "quantifiés" (par exemple kilo en Ko) en octets décimaux (base 10, 1000) par opposition aux octets binaires (base 2, 1024), alors je "quantifie" en divisant par 1000 et en augmentant le préfixe d'unité (octet) «quantificateur» (amplitude) et faire quelques arrondis «hors clé» impairs. (Mon code complet est plein de code de développement non commenté et divisé en plusieurs fichiers (et langues), il est donc difficile de partager.)
  Pour autant que j'ai vu mes chiffres `` quantifiés '' sont les mêmes que les chiffres `` quantifiés '' dans le Finder .
  
• De plus, avec le code, je veux dire que je n'ai (et je n'ai jamais eu) de variable d'environnement BLOCKSIZEdéfinie dans mon shell, mais j'ai testé (maintenant, un peu) les deux versions et les valeurs par défaut de $BLOCKSIZEdonne les mêmes valeurs.
  

#!/usr/bin/env bash
#tab-width:4
                                 du -s                      "${@:-.}"   |awk '{u+=$1}END{   print  u*'${BLOCKSIZE:-0512}'   }'||exit $?         #macosx  (xnu)
#                               gdu -sB${BLOCKSIZE:-4096}   "${@:-.}"   |awk '{u+=$1}END{   print  u*'${BLOCKSIZE:-4096}'   }'||exit $?         #macports gnu

• Le nombre non quantifié que je n'ai pas réussi à égaler.
  La seule chose que je peux dire est que je me rapproche en comptant uniquement les fichiers (excluant ainsi le répertoire ~ 'méta-index / en-tête du système de fichiers' ~ données) et que le plus proche que j'obtiens est avec ce qui suit.

#!/usr/bin/env bash
#tab-width:4
    for a;do find "$a" -type f -print0|xargs -0      stat -f %z         |awk '{u+=$1}END{   print  u                        }'||exit $?;done    #macosx  (xnu)
#   for a;do find "$a" -type f -print0|xargs -0     gstat -c %s         |awk '{u+=$1}END{   print  u                        }'||exit $?;done    #macports gnu

• Ni (xnu) du(1) ni (gnu) gdu(1) ne semblent compter les attributs étendus ( xattr)

Et puis je dois juste punir «Courez le chemin et faites le calcul»
Paix et bonne nuit pour cette fois.

Sur mon système Ubuntu, en utilisant ext4, du -b filedonne la taille en octets d'un fichier réel, et du -b dirdonne la taille en octets du fichier (s) + surcharge du répertoire, la surcharge est, dans mon cas, des multiples de 4096 octets ..

Cette surcharge augmente à mesure que le nombre de fichiers augmente.
Remarque: même si les fichiers sont supprimés, la surcharge du répertoire reste au niveau supérieur où elle se trouvait avant la suppression des fichiers.

Je n'ai pas essayé de redémarrer, pour voir s'il revient, mais dans les deux cas, cela signifie que la taille du répertoire varie en fonction des circonstances historiques.

Compter la taille de chaque fichier peut être la meilleure option pour une valeur précise de la taille totale des fichiers .

Le script suivant totalise toutes les tailles de fichiers (en octets).

Pour OS X, si vous n'avez pas l' -bopton pour 'du', vous pouvez utiliser à la statplace. (Si vous l'avez :) ... La ligne commentée montre l' statalternative Ubuntu à du -b;

unset total
while IFS= read -r -d $'\0' rf; do
  # (( total += $(stat  "$rf" | sed -nre 's/^  Size: ([0-9]+).*/\1/p') ))
    (( total += $(du -b "$rf" | cut -f 1) ))
done < <(find  . -type f  -name '*' -print0)
echo $total

Additionnez tous les fichiers dans un répertoire:

OSX: find dir ! -type d -print0 | xargs -0 stat -f '%z' | awk '{sum += $1} END{print sum}'

Linux: find dir ! -type d -printf "%s\n" | awk '{sum += $1} END{print sum}'