Pourquoi ls -l génère-t-il une taille différente de ls -s?

Question

Pourquoi ls -l génère-t-il une taille différente de ls -s?

#1 de phoibos (38 votes)
#2 de guntbert (13 votes)

31

Je n'arrive pas à comprendre pourquoi j'obtiens les résultats suivants:

ls -l me dit que la taille d'un fichier donné (HISTORY) est "581944":

$ ls -l HISTORY 
-rw-rw-r-- 1 waldir waldir 581944 Feb 22 10:59 HISTORY

ls -s dit que c'est "572":

$ ls -s HISTORY
572 HISTORY

Je dois évidemment faire en sorte que les valeurs utilisent une échelle comparable. Donc, tout d'abord, je confirme que l'utilisation de --block-size 1 en ls -l me donne le même résultat qu'auparavant:

$ ls -l --block-size 1 HISTORY 
-rw-rw-r-- 1 waldir waldir 581944 Feb 22 10:59 HISTORY

Ensuite, je fais la même chose avec ls -s pour obtenir une valeur de la même échelle:

$ ls -s --block-size 1 HISTORY 
585728 HISTORY

Des résultats différents! 581944 <585728 .

J'ai essayé de générer des valeurs comparables dans l'autre sens, en utilisant -k , mais j'obtiens:

$ ls -lk HISTORY 
-rw-rw-r-- 1 waldir waldir 569 Feb 22 10:59 HISTORY
$ ls -sk HISTORY 
572 HISTORY

Encore une fois, différents résultats, 569 ≠ 572 .

J'ai essayé de spécifier --si pour s’assurer que les deux options utilisaient la même échelle, sans succès:

$ ls -lk --si HISTORY 
-rw-rw-r-- 1 waldir waldir 582k Feb 22 10:59 HISTORY
$ ls -sk --si HISTORY 
586k HISTORY

... encore une fois, différentes valeurs: 582k <586k .

J'ai essayé de chercher sur le Web, mais la seule chose que je pouvais trouver pertinente était this :

Certains fichiers comportent des "trous", de sorte que l’utilisation indiquée par ls -s (...) est inférieure à la taille de fichier indiquée par ls -l . "

(notez que dans mes résultats, le contraire se produit: ls -s renvoie des tailles supérieures à ls -l , et non plus petites.)

Entre-temps, cette page indique que

il n'y a pas de moyen élégant pour détecter les trous de fichiers Unix.

Alors, comment puis-je gérer cette divergence? Laquelle de ces valeurs peut être considérée comme correcte? Est-ce que cela pourrait être un bogue dans ls ?

command-line ls

posée waldyrious 18.03.2013 - 13:42

la source

2 réponses

13

ls -s vous indique la taille allouée du fichier, toujours un multiple de l'unité d'allocation. ls -l indique la taille réelle. Un moyen facile de tester:

echo 1 > sizeTest
ls -l --block-size 1 sizeTest 
-rw-rw-r-- 1 g g 2 Mär 18 15:18 sizeTest
ls -s --block-size 1 sizeTest 
4096 sizeTest

réponse donnée guntbert 18.03.2013 - 15:20

la source

Lire d'autres questions sur les étiquettes command-line ls

X11 Transfert sur écran Gnu, est-ce possible? Comment installer jekyll?

score 38 · Accepted Answer

Réponse courte:

ls -l donne la taille du fichier (= la quantité de données qu'il contient)
ls -s --block-size 1 donne la taille du fichier sur le système de fichiers

Créez deux fichiers:

Un fichier fragmenté d’une longueur de 128 octets (un fichier fragmenté est un fichier contenant des blocs vides, voir Sparse Fichier ):

# truncate -s 128 f_zeroes.img
# hexdump -vC f_zeroes.img 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080

Un autre fichier avec des données aléatoires, également de taille 128 octets:

# dd if=/dev/urandom of=f_random.img bs=1 count=128
# hexdump -vC f_random.img 
00000000  bc 82 9c 40 04 e3 0c 23  e6 76 79 2f 95 d4 0e 45  |[email protected]#.vy/...E|
00000010  19 c6 53 fc 65 83 f8 58  0a f7 0e 8f d6 d6 f8 b5  |..S.e..X........|
00000020  6c cf 1b 60 cb ef 06 c6  d0 99 c6 16 3f d3 95 02  |l..'........?...|
00000030  85 1e b7 80 27 93 27 92  d0 52 e8 72 54 25 4d 90  |....'.'..R.rT%M.|
00000040  11 59 a2 d9 0f 79 aa 23  2d 44 3d dd 8d 17 d9 36  |.Y...y.#-D=....6|
00000050  f5 ae 07 a8 c1 b4 cb e1  49 9e bc 62 1b 4f 17 53  |........I..b.O.S|
00000060  95 13 5a 1c 2a 7e 55 b9  69 a5 50 06 98 e7 71 83  |..Z.*~U.i.P...q.|
00000070  5a d0 82 ee 0b b3 91 82  ca 1d d0 ec 24 43 10 5d  |Z...........$C.]|
00000080

Ainsi, comme vous pouvez le voir dans la représentation hexadécimale, les deux fichiers ont la même quantité de données , bien que le contenu soit assez différent.

Voyons maintenant le répertoire

# ls -ls --block-size 1 f_*
1024 -rw-r--r-- 1 user user 128 Mar 18 15:34 f_random.img
   0 -rw-r--r-- 1 user user 128 Mar 18 15:32 f_zeroes.img
   ^                         ^
   |                         |
Amount which the           Actual file size
files takes on the fs

La première valeur est donnée par l'option -s --block-size 1 , c'est la quantité d'espace utilisée par le fichier sur le système de fichiers .

Comme vous pouvez le constater, le fichier fragmenté ne contient aucun espace, car le système de fichiers ( ext3 dans ce cas) était suffisamment intelligent pour reconnaître qu'il ne contenait que des zéros. En outre, le fichier contenant des données aléatoires occupe 1024 octets sur le disque!

La valeur dépend de la manière dont le système de fichiers sous-jacent traite les fichiers (taille des blocs, capacité des fichiers fragmentés, etc.).

Dans la sixième colonne se trouve la taille du fichier si vous le lisez - c'est la quantité de données que le fichier contient et 128 octets pour les deux fichiers!