Que compte la fonction "du"?

Version imprimable

Bonjour à tous,

Après avoir lu le man de la fonction "du", j'ai lancé cette commande pour connaitre la taille d'un répertoire et de son contenu.

Code:

du -ba ProFolder

le résultat m'a quelque peu... surpris:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 107 ProFolder/.svn/all-wcprops 219 ProFolder/.svn/entries 2 ProFolder/.svn/format 0 ProFolder/.svn/prop-base 0 ProFolder/.svn/props 0 ProFolder/.svn/text-base 0 ProFolder/.svn/tmp/prop-base 0 ProFolder/.svn/tmp/props 0 ProFolder/.svn/tmp/text-base 0 ProFolder/.svn/tmp 4424 ProFolder/.svn 4424 ProFolder
à ce que je sache 107+219+2 = 328 alors comment est ce que la commande arrive à un total de 4424?? 8O

Quelqu'un aurait il une explication?
Sachant qu'un clic droit à l'intérieur du répertoire .svn indique bien 328 bytes...

Merci

28/06/2009, 22h46
Invité

Salut,

Un repertoire sans inclure les fichiers qu'il contient fait a lui seul une taille de 4k (4096 octets)

Donc si on doit faire la somme de tout ce qu'il y a dans ProFolder on a:

le repertoire .svn = 4096 octets (tu pourras voir sa taille en tapant la commande ls -ld .svn) + tes trois autres fichiers dont la somme est de 328 octets = 4424 octets au total.
28/06/2009, 23h11
Sunsawe

je crois voir ce que tu veux dire mais... du coup, il y a autre chose que je ne comprends pas.
Dans le répertoire .svn, il y a un répertoire tmp qui contient des fichiers, tous de 0 octet.
Pourquoi le répertoire n'est il pas alors compté comme pesant 4096 octets?
Est ce que cette taille minimale est standard ou elle peut varier?
29/06/2009, 00h03
Invité
Le repertoire lui-même à ma connaissance a toujours cette taille à moins que ce soit un lien sur le repertoire en question

Le repertoire tmp est-il bien un repertoire et non un lien symbolique?

pourrais-tu fournir le résultat de la commande suivante pour avoir plus de détail?
Code:

1 2 ls -lRa .svn
Pourrais-tu également me dire quelle distribution tu utilises?
29/06/2009, 00h13
Sunsawe

Voilà le résultat:

Citation:

ls -lRa .svn
.svn:
total 9
drwxrwxrwx 1 root root 4096 2009-06-28 22:17 .
drwxrwxrwx 1 root root 0 2009-06-26 16:05 ..
-rwxrwxrwx 1 root root 444 2009-06-26 16:13 all-wcprops
-rwxrwxrwx 1 root root 704 2009-06-26 16:13 entries
-rwxrwxrwx 1 root root 2 2009-06-26 16:05 format
drwxrwxrwx 1 root root 0 2009-06-26 16:13 prop-base
drwxrwxrwx 1 root root 0 2009-06-26 16:13 props
drwxrwxrwx 1 root root 0 2009-06-26 16:13 text-base
drwxrwxrwx 1 root root 0 2009-06-26 16:13 tmp

.svn/prop-base:
total 6
drwxrwxrwx 1 root root 0 2009-06-26 16:13 .
drwxrwxrwx 1 root root 4096 2009-06-28 22:17 ..
-rwxrwxrwx 1 root root 30 2009-06-26 16:06 FAHlog.txt.svn-base
-rwxrwxrwx 1 root root 79 2009-06-26 16:06 maj.png.svn-base
-rwxrwxrwx 1 root root 30 2009-06-26 16:06 unitinfo.txt.svn-base

.svn/props:
total 4
drwxrwxrwx 1 root root 0 2009-06-26 16:13 .
drwxrwxrwx 1 root root 4096 2009-06-28 22:17 ..

.svn/text-base:
total 61
drwxrwxrwx 1 root root 0 2009-06-26 16:13 .
drwxrwxrwx 1 root root 4096 2009-06-28 22:17 ..
-rwxrwxrwx 1 root root 25822 2009-06-26 16:13 FAHlog.txt.svn-base
-rwxrwxrwx 1 root root 26579 2009-06-26 16:13 maj.png.svn-base
-rwxrwxrwx 1 root root 174 2009-06-26 16:13 unitinfo.txt.svn-base

.svn/tmp:
total 4
drwxrwxrwx 1 root root 0 2009-06-26 16:13 .
drwxrwxrwx 1 root root 4096 2009-06-28 22:17 ..
drwxrwxrwx 1 root root 0 2009-06-26 16:05 prop-base
drwxrwxrwx 1 root root 0 2009-06-26 16:06 props
drwxrwxrwx 1 root root 0 2009-06-26 16:13 text-base

.svn/tmp/prop-base:
total 0
drwxrwxrwx 1 root root 0 2009-06-26 16:05 .
drwxrwxrwx 1 root root 0 2009-06-26 16:13 ..

.svn/tmp/props:
total 0
drwxrwxrwx 1 root root 0 2009-06-26 16:06 .
drwxrwxrwx 1 root root 0 2009-06-26 16:13 ..

.svn/tmp/text-base:
total 0
drwxrwxrwx 1 root root 0 2009-06-26 16:13 .
drwxrwxrwx 1 root root 0 2009-06-26 16:13 ..

J'utilise ubuntu 9.04.

Re,

Le calcul de la commande du est bien correct car la taille des repertoires suivants sont à 0 (ce qui m'étonne d'ailleurs)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 svn: total 9 drwxrwxrwx 1 root root 4096 2009-06-28 22:17 . -> repertoire .svn drwxrwxrwx 1 root root 0 2009-06-26 16:05 .. -rwxrwxrwx 1 root root 444 2009-06-26 16:13 all-wcprops -> je suppose que la taille a changé entre-temps? -rwxrwxrwx 1 root root 704 2009-06-26 16:13 entries -rwxrwxrwx 1 root root 2 2009-06-26 16:05 format drwxrwxrwx 1 root root 0 2009-06-26 16:13 prop-base drwxrwxrwx 1 root root 0 2009-06-26 16:13 props drwxrwxrwx 1 root root 0 2009-06-26 16:13 text-base drwxrwxrwx 1 root root 0 2009-06-26 16:13 tmp
utiliserais-tu un autre filesystem que l'ext3 par hasard?
Code:

1 2 mount
pour voir tes différents filesystem + indiquer sur quel filesystem le repertoire Profolder est monté.

29/06/2009, 08h23
Sunsawe

voici la ligne qui correspond:

Citation:

/dev/sda5 on /media/Data type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)

Il me semble que la partition est formatée en NTFS. Elle sert d'échange entre les deux systèmes installés.

la commande "du" "classique" ne compte pas des tailles de fichier effective, mais un nombre de blocs utilisée par un fichier. ainsi :
Code:

1 2 3 4 5 6 7 ls -l total 1608 -rwxr--r-- 1 marc marc 16186 2009-05-06 09:42 config.txt ...... du acces.txt config.txt 16 config.txt
le fichier config.txt pése 16186 octets, mais occupe 16 "blocs" (standart 1k en générale).
Code:

1 2 3 du -b config.txt 16186 config.txt
Citation:

-b, --bytes
équivalent à « --apparent-size --block-size=1 »

Me donne le nombre d'octet.

Le system de fichier ne sait pas accéder au disque autrement que par "bloc entier", si la taille d'un fichier n'est pas un multiple de la taille du bloc, la différence du multiple immédiatement supérieur est "perdu" en taille (un autre fichier ne pourra pas y être "rangé").

Avec des blocs disque de 2k 10 fichiers de 120 octets occuperont 10k d'espace disque "utile".

visible par :
tune2fs -l /mon_filesystem
exemple
Code:

1 2 3 4 5 6 7 8 9 10 11 12 tune2fs -l /dev/sdd5 tune2fs 1.40.8 (13-Mar-2008) Filesystem volume name: backup Filesystem OS type: Linux ...... Inode count: 30490624 Block count: 121961448 Reserved block count: 6098072 Free blocks: 97917403 Free inodes: 30339027 First block: 0 Block size: 4096
ici blocs de 4k
donc si 10 fichier de 120 octets 40K d'usage disque........

29/06/2009, 14h15
Sunsawe

je suis tout à fait d'accord, mais ça ne m'explique pas pourquoi, avec l'option -b de du, certains répertoires soient reportés pesant 4096 octet et d'autre 0.

Là on ne parle pas de bloc (même si visiblement un bloc = 4096 donc un répertoire occuperait un bloc). C'est l'inconsistance du résultat qui m'étonne.

La seule piste que j'ai pu repérer, est que cela puisse venir du système fichier. En effet sur une partition ext3 tous les répertoires sont indiqués comme pesant 4096 octets.
07/05/2010, 11h17
Sunsawe

je confirme après divers essais que l'inconsistence venait de l'utilisation de NTFS comme système de fichiers.