次の結果が得られる理由がわかりません：
ls -l </ code> 特定のファイル（HISTORY）のサイズが「581944」であることを教えてくれます：
$ ls -l HISTORY
-rw-rw-r-- 1 waldyrious waldyrious 581944 Feb 22 10:59 HISTORY
ls -s 「572」だと言う：
$ ls -s HISTORY
572 HISTORY
明らかに、値に同等のスケールを使用させる必要があります。そこで、最初に-block-size 1を使用していることを確認します ls -lで 以前と同じ結果が得られます：
$ ls -l --block-size 1 HISTORY
-rw-rw-r-- 1 waldyrious waldyrious 581944 Feb 22 10:59 HISTORY
次に、 ls -sに対して同じことを行います 同じスケールの値を取得するには：
$ ls -s --block-size 1 HISTORY
585728 HISTORY
異なる結果！ 581944≠585728 。
-k を使用して、逆に同等の値を生成してみました 、しかし私は得る：
$ ls -lk HISTORY
-rw-rw-r-- 1 waldyrious waldyrious 569 Feb 22 10:59 HISTORY
$ ls -sk HISTORY
572 HISTORY
繰り返しますが、異なる結果、569≠572 。
–siを指定して、両方のオプションが同じスケールを使用していることを確認してみましたが、役に立ちませんでした：
$ ls -lk --si HISTORY
-rw-rw-r-- 1 waldyrious waldyrious 582k Feb 22 10:59 HISTORY
$ ls -sk --si HISTORY
586k HISTORY
…繰り返しますが、異なる値：582k≠586k 。
ウェブを検索してみましたが、関連性があると思われるのはこれだけでした：
一部のファイルには「穴」が含まれているため、
ls -sで使用法がリストされています。 （…）ls -lでリストされたファイルサイズよりも小さい 。」
（私の結果では、逆のことが起こることに注意してください： ls -s ls -lより大きいサイズを返します 、小さくはありません。）
その間、このページはそれを言います
Unixファイルの穴を検出する洗練された方法はありません。
では、どうすればこの不一致に対処できますか？これらの値のどれが正しいと見なすことができますか？これはlsのバグである可能性があります ？
ベストアンサー
簡単な答え：
-
ls -l </ code> ファイルのサイズ（=ファイルに含まれるデータの量）を示します -
ls -s --block-size 1ファイルシステム上のファイルのサイズを示します
2つのファイルを作成しましょう：
スパースファイル 128バイトの長さ（スパースファイルは空のブロックを含むファイルです。スパースファイルを参照してください）：
# 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
同じく128バイトサイズのランダムデータを含む別のファイル：
# 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
したがって、16進表現でわかるように、両方のファイルには同じ量のデータがあります。 、内容はかなり異なりますが。
関連：DELL XPS139360上のUbuntu16.10–（どのように）Intelグラフィックスドライバーを使用しますか？では、ディレクトリを見てみましょう：
# 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
最初の値は-s--block-size 1で指定されます オプションの場合、これはファイルシステム上のファイルによって使用されるスペースの量です。 。
ご覧のとおり、ファイルシステム（ ext3 ）のため、スパースファイルはゼロスペースを占有します。 この場合）は、ゼロのみが含まれていることを認識するのに十分賢いです。また、ランダムデータを含むファイルはディスク上で1024バイトを占めます！
この値は、基盤となるファイルシステムがファイルを処理する方法（ブロックサイズ、スパースファイル機能など）によって異なります。
6番目の列は、ファイルを読み取る場合のファイルのサイズです。これは、ファイルに含まれるデータの量です。 両方のファイルで128バイトです！