Por que du informa um tamanho de 0 para alguns arquivos não vazios em uma partição HFS +?

Question

Qual é a explicação para a diferença:

$ ls -l /Applications/Safari.app/Contents/Info.plist
-rw-r--r--  1 root  wheel  15730 11 jui 15:02 /Applications/Safari.app/Contents/Info.plist

$ du -sh /Applications/Safari.app/Contents/Info.plist
0B     /Applications/Safari.app/Contents/Info.plist

Quando o arquivo é copiado na minha pasta pessoal, ls e du informam o mesmo número.

$ cp /Applications/Safari.app/Contents/Info.plist .
$ du -sh Info.plist; ls -l Info.plist
16K Info.plist
-rw-r--r--  1 ant  staff  15730 17 oct 16:53 Info.plist

Ambos os diretórios estão nesta partição (/)

diskutil  info /
Device Identifier:        disk0s2
Device Node:              /dev/disk0s2
Part of Whole:            disk0
Device / Media Name:      ml2013

Volume Name:              OSX.10.8
Escaped with Unicode:     OSX.10.8

Mounted:                  Yes
Mount Point:              /
Escaped with Unicode:     /

File System Personality:  Journaled HFS+
Type (Bundle):            hfs
Name (User Visible):      Mac OS Extended (Journaled)
Journal:                  Journal size 40960 KB at offset 0xc83000
Owners:                   Enabled

Aqui está a saída do stat:

$ stat  Info.plist
16777218 8780020 -rw-r--r-- 1 root wheel 0 15730 "Oct 17 17:47:12 2013" \ 
"Jun 11 15:02:17 2013" "Jun 11 15:02:17 2013" "Apr 27 11:49:34 2013"\ 
4096 0 0x20 Info.plist

    

Answer 1

Eu posso ter encontrado algo:

O comando ls no OS X tem essa opção:

  -O      Include the file flags in a long (-l) output.

O resultado é:

$ ls -O Info.plist
-rw-r--r--  1 root  wheel  compressed 15730 11 jui 15:02 Info.plist

Acabei de verificar (experimentalmente) que du sempre reporta 0 para arquivos compactados HFS +.

Copiar arquivos compactados os descompacta; então, logicamente du informa o arquivo correto em um arquivo copiado e descompactado.

Aqui está uma explicação para o comportamento de du :

Compressão de arquivos HFS +

In Mac OS X 10.6, Apple introduced file compression in HFS+. Compression is most often used for files installed as part of Mac OS X; user files are typically not compressed (but certainly can be!). Reading and writing compressed files is transparent as far as Apple's file system APIs.

Compressed files have an empty data fork. This means that forensic tools not aware of HFS+ file compression (including TSK before 4.0.0) will not see any data associated with a compressed file!

Há também uma discussão sobre este assunto em Mac OS X and iOS Internals: To the Apple's Core por Jonathan Levin, no capítulo 16: Para B (-Tree) ou não ser - Os sistemas de arquivos HFS +.

O afsctool também ajuda a ver quais arquivos são compactados em uma pasta.

$ afsctool -v /Applications/Safari.app/
/Applications/Safari.app/.:
Number of HFS+ compressed files: 1538
Total number of files: 2247
Total number of folders: 144
Total number of items (number of files + number of folders): 2391
Folder size (uncompressed; reported size by Mac OS 10.6+ Finder): 29950329 bytes / 34.7 MB (megabytes) / 33.1 MiB (mebibytes)
Folder size (compressed - decmpfs xattr; reported size by Mac OS 10.0-10.5 Finder): 21287197 bytes / 23.8 MB (megabytes) / 22.7 MiB (mebibytes)
Folder size (compressed): 22694835 bytes / 25.2 MB (megabytes) / 24 MiB (mebibytes)
Compression savings: 24.2%
Approximate total folder size (files + file overhead + folder overhead): 26353338 bytes / 26.4 MB (megabytes) / 25.1 MiB (mebibytes)

    

Answer 2

Ao usar du e você está comparando os resultados de duas execuções diferentes com sistemas de arquivos, é necessário usar a opção --apparent-size .

Exemplo

Aqui está um compartilhamento montado em CIFS.

$ du -sh somedir
50M somedir

$ du -sh --apparent-size somedir
45M somedir

trecho da página du man

--apparent-size
          print  apparent  sizes,  rather than disk usage; although the apparent 
          size is usually smaller, it may be larger due to holes in (‘sparse’)
          files, internal fragmentation, indirect blocks, and the like

Então, o que está acontecendo?

Isso confunde muitas pessoas, mas lembre-se de que, quando arquivos são armazenados em um disco, eles consomem blocos de espaço, mesmo que estejam usando apenas uma parte desses blocos. Quando você executa du sem o --apparent-size , está obtendo o tamanho com base na quantidade de espaço em bloco do disco usado, não no espaço real consumido pelo (s) arquivo (s).

E quanto ao tamanho 0B?

0B /Applications/Safari.app/Contents/Info.plist

Este é provavelmente um link. Fazer este comando mostrará se esse é o caso.

$ ls -l /Applications/Safari.app/Contents | grep Info.plist

    

Answer 3

A minha resposta está em linha com os outros, mas ainda não posso comentar, pelo que posso começar de novo:

A maioria dos arquivos em / Applications é compactada e quando você a copia é perdida. Quando a compactação é usada no HFS +, os dados do arquivo são armazenados no Fork de Recursos OU um atributo estendido se for pequeno o suficiente (menor que 4k). Se estiver em um fork do recurso (pelo menos no Yosemite) irá mostrar o uso real do disco em blocos. Se estiver inteiramente no atributo, ele mostrará 0.