Caso em questão: TextEdit da Apple em/Applications/TextEdit.app
Se você calcular o tamanho físico, echo "$(/usr/bin/du -k -d 0 /Applications/TextEdit.app | /usr/bin/awk '{print $1}') * 1024" | /usr/bin/bc -l
obterá (no meu caso em 10.11.6) um tamanho de4538368 bytes.
No entanto, se você abrir a janela Informações no Finder, será informado que o tamanho físico é muito maior:8,6 MB em disco, quase o dobro do tamanho.
Está claro o porquê: a Apple usou compactação HFS no TextEdit. Executando a ferramenta de terceirosafsctool(que você pode instalar com o Homebrew) produz este resultado:
/usr/local/bin/afsctool /Applications/TextEdit.app /Applications/TextEdit.app: Number of HFS+ compressed files: 693
Agora, o macOS obviamente parece conhecer o tamanho físico descompactado, conforme evidenciado pelo valor do tamanho no disco na janela Informações do Finder.
Minha pergunta é: se existe uma maneira somente leitura de linha de comando para obter essas informações, ou seja, uma maneira de mostrar:
(a) otamanho físico não compactado(uso de disco) de um arquivo compactado em HFS, ou seja, um arquivo para o qual /usr/bin/stat -f %f
retorna "32" (mesmo que seja "524320" por algum motivo no TextEdit), e
(b) otamanho físico total não compactado(uso de disco) de um diretório ou pacote que contém arquivos compactados HFS.
Observação:apenas comandos nativos do macOS devem ser usados para calcular o tamanho, enquantonãousando dados dependentes do Spotlight, por exemplo, do mdls
comando, que apresenta erros e às vezes retorna (null)
para a kMDItemPhysicalSize
chave, além do fato de que alguns usuários desabilitaram completamente o Spotlight.
Responder1
Usarafsctool
comando com -v
flag, por exemplo:
$ afsctool -v README
README:
File is HFS+ compressed.
File size (uncompressed data fork; reported size by Mac OS 10.6+ Finder): 3046 bytes / 3 KB (kilobytes) / 3 KiB (kibibytes)
File size (compressed data fork - decmpfs xattr; reported size by Mac OS 10.0-10.5 Finder): 0 bytes / 0 KB (kilobytes) / 0 KiB (kibibytes)
File size (compressed data fork): 1427 bytes / 1 KB (kilobytes) / 1 KiB (kibibytes)
Compression savings: 53.2%
Number of extended attributes: 0
Total size of extended attribute data: 0 bytes
Approximate overhead of extended attributes: 268 bytes
Approximate total file size (compressed data fork + EA + EA overhead + file overhead): 1943 bytes / 2 KB (kilobytes) / 2 KiB (kibibytes)
Responder2
Bem, afsctool
foi removido do macOS e du
funciona em diretórios inteiros:
% ditto -v --hfsCompression --arch arm64 /Volumes/Thunderbird/Thunderbird.app \
/Applications/Thunderbird\ BETA\ V.99.ARM64.app
Copying /Volumes/Thunderbird/Thunderbird.app [arm64]
% ditto -v --hfsCompression /Volumes/Thunderbird/Thunderbird.app
/Applications/Thunderbird\ BETA\ V.99.UNIVERSAL.app
Copying /Volumes/Thunderbird/Thunderbird.app
% du -sk /Applications/Thunderbird* /Volumes/Thunderbird/Thunderbird.app
352808 /Applications/Thunderbird BETA V.94.Universal.app
74832 /Applications/Thunderbird BETA V.99.ARM64.app
133152 /Applications/Thunderbird BETA V.99.UNIVERSAL.app
349184 /Applications/Thunderbird.app
349184 /Volumes/Thunderbird/Thunderbird.app
% du -skA /Applications/Thunderbird\ BETA\ V.99.*
207938 /Applications/Thunderbird BETA V.99.ARM64.app
348917 /Applications/Thunderbird BETA V.99.UNIVERSAL.app
%
Da documentação:
du: -A
exibe o tamanho aparente em vez do uso do disco. Isto pode ser útil ao operar em volumes compactados ou arquivos esparsos
(Eu me pergunto por que e quando o afsctool foi removido do macOS, se ele pode ser copiado de uma instalação antiga e se está no Darwin.)
Ah, e quanto aos mdls, isso funciona melhor com o sleep:
% cat /dev/urandom | head -c 5 > foo; sleep 3; mdls foo | grep ize
kMDItemFSSize = 5
kMDItemLogicalSize = 5
kMDItemPhysicalSize = 4096
contra
% cat /dev/urandom | head -c 2 > foo; mdls foo | grep ize
kMDItemFSSize = (null)
Além disso, a saída depende do diretório atual; ele age de maneira diferente em /tmp vs ~.