O Mac OS X não informa corretamente os tamanhos dos diretórios?

Question 1

As diferenças vieram de diferentes motivos: diferentes formas de contagem, diferentes ferramentas, compressão e o que parece ser um bug.

Oprimeira diferençaem tamanho que você vê parece ser umbug no Finder. Os tamanhos dos arquivos mostrados pelo Finder são calculados de alguma forma em tempo real e armazenados em cache nos .DS_Storearquivos. Por alguma razão, ao duplicar um grande aplicativo/pasta, o Finder calcula seu tamanho durante o processo de cópia e armazena em cache o tamanho, então incompleto. Em seguida, ele mostra esse tamanho em cinza nas janelas do Finder, cinza significandoo Finder sabe que o conteúdo mudou desde o último cálculo de tamanho, mas ainda não o recalculou.

A única maneira que encontrei de recalcular corretamente o tamanho é excluindo o .DS_Storearquivo na pasta Aplicativo, fechando o Finder (no Activity Monitor, por exemplo) e reiniciá-lo novamente (no ícone do Dock). Se você não excluir o .DS_Storearquivo, ele ainda permanecerá acinzentado. Talvez esperandoàs vezes(horas, dias, reinicialização, ...) fará com que o Finder faça isso sozinho.

Depois disso, você verá que todos os tamanhos relatados pelo Finder são iguais.

Então, sim, parece um bug do Finder, pelo menos no OSX Lion (testado com 10.7.4 aqui, Finder versão 10.7.3). Você também pode vereste tópicoque relata o mesmo tipo de comportamento.

Então, vamos considerar a duferramenta. A princípio, pensei que a diferença que vemos poderia ser explicada pela diferença entre os tamanhos lógicos e físicos dos itens que estão sendo copiados. O tamanho lógico é orealtamanho do item, ou seja, cada pedaço de informação que ele contém somado. O tamanho físico é o tamanho do item no disco, onde cada bit de informação é gravado em um setor do disco.

Por exemplo, um arquivo contendo um único caractere acabaria tendo um tamanho lógico de 1 byte, mas um tamanho físico de 512 bytes ou mesmo 4.096 bytes quando realmente gravado no disco. O tamanho físico geralmente é maior que o tamanho lógico (e depende do tamanho real do setor/bloco do disco ou do sistema de arquivos). Isso éexplicado em mais detalhes neste outro tópico. O tamanho lógico pode ser maior no caso dearquivos esparsos, mas o HFS+ não parece oferecer suporte a esse recurso.

dumostra apenas o tamanho físico (e você pode dizer o que é BLOCKSIZE). Você pode ver que o tamanho informado por dué sempre maior (ou, excepcionalmente, igual) ao original. Isso ocorre devido à fragmentação do sistema de arquivos e do espaço em disco. Quando você copia um arquivo (na verdade, aqui um monte de arquivos, já que um Aplicativo é um diretório), novos setores são alocados no disco e,à medida que ocorre a fragmentação, o número de blocos usados geralmente é maior que o do item original. Algumas pessoas chamam issoFolga de arquivo.

Agora, de volta ao Finder. Se você abrir oobter informaçãojanela dos aplicativos que você duplicou, você verá que o Finder está realmente relatando o tamanho lógico e físico do item que você selecionou. O que então faz sentido. Você ainda poderá comparar o tamanho físico relatado pelo Finder e aquele relatado por duse fizer um pouco de matemática.

Por que fazer algumas contas? Porque o Finder mostra os tamanhos dos arquivos em kB, MB ou GB, onde duos reporta em kiB, MiB ou GiB. Esses são osPrefixos binários IECque deve ser usado para calcular e exibir unidades de informação digital.

Mas, na verdade, não tenho certeza se o File Slack está envolvido aqui, há outra coisa. Volumes HFS+ permitem compactação, feito de forma transparente, e a Apple usa isso para os itens originais instalados pelo sistema operacional. Então, quando os arquivos são copiados usando ferramentas padrão, a compactação não é mais usada (como padrão, para ser compatível com versões anteriores). Se quiser manter a compactação desses arquivos, você precisará usar o dittocomando em vez de cpqualquer ação do Finder. Isso éexplicado nesta revisão.

Aqui está o resultado da cópia do iTunes.app usando diferentes técnicas. Você verá que idem deixa o Aplicativo exatamente do mesmo tamanho, preservando a compactação, onde cpnão. E você pode até remover o binário do arco que não precisa, reduzindo então todo o tamanho):

antoine@amarante:/Applications$ du -ms iTunes.app/
281 iTunes.app/
antoine@amarante:/Applications$ cp -a iTunes.app/ iTunes-copy.app/
antoine@amarante:/Applications$ ditto iTunes.app/ iTunes-ditto.app
antoine@amarante:/Applications$ ditto --arch x86_64 iTunes.app/ iTunes-64.app
antoine@amarante:/Applications$ du -ms iTunes*
236 iTunes-64.app
289 iTunes-copy.app
281 iTunes-ditto.app
281 iTunes.app

Obrigado a @DanPritts por sua respostano meu post complementar.

Answer