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

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

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

Assim que o arquivo for copiado para minha pasta pessoal, lsinforme duo 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 de 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

Responder1

Posso ter encontrado algo:

O comando ls no OS X tem esta 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 dusempre reporta 0arquivos compactados HFS +.

Copiar arquivos compactados e descompactá-los; então durelata logicamente o arquivo correto em um arquivo copiado e descompactado.

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

Compressão de arquivo HFS+

No Mac OS X 10.6, a Apple introduziu a compactação de arquivos em HFS+. A compactação é usada com mais frequência para arquivos instalados como parte do Mac OS X; os arquivos do usuário normalmente não são compactados (mas certamente podem ser!). Ler e gravar arquivos compactados é transparente no que diz respeito às APIs do sistema de arquivos da Apple.

Os arquivos compactados possuem uma bifurcação de dados vazia. Isso significa que as ferramentas forenses que não conhecem a compactação de arquivos HFS+ (incluindo TSK antes da versão 4.0.0) não verão nenhum dado associado a um arquivo compactado!

Há também uma discussão sobre esse assunto em Mac OS X and iOS Internals: To the Apple's CoreJonathan Levin, no capítulo 16: To B(-Tree) or not to be - The HFS+ filesystems.

Tambémafsctoolpode ajudar a ver quais arquivos estã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)

Responder2

Ao usar due comparar os resultados de duas execuções diferentes com sistemas de arquivos, certifique-se de usar o switch --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 de manual

--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, como vai?

Isso confunde muitas pessoas, mas lembre-se de que quando os 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 dusem, --apparent-sizeobtém 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 o tamanho 0B?

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

Provavelmente é um link. Executar este comando mostrará se este é o caso.

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

Responder3

Minha resposta está alinhada com outras, mas ainda não posso comentar, então começo de novo:

A maioria dos arquivos em /Applications são compactados e quando você os copia, eles são perdidos. Quando a compactação é usada em HFS+, os dados dos arquivos são armazenados no Resource ForkOUum atributo estendido se for pequeno o suficiente (menos de 4k). Se estiver em um fork de recursos du (pelo menos no Yosemite) mostrará o uso real do disco em blocos. Se estiver inteiramente no atributo, mostrará 0.

informação relacionada