O Mac OS X não informa os tamanhos de diretório corretamente?

No Finder, observei que, se eu duplicar alguns arquivos .app (na pasta Aplicativos), o Finder mostrará que o arquivo .app duplicado não tem o mesmo tamanho que o original. Essa discrepância de tamanho de arquivo não ocorre em todos os arquivos .app que eu duplico, mas parece que quanto maior o arquivo .app, maior a probabilidade de que o duplicado não mostre o mesmo tamanho que o original. aqui estão alguns exemplos:

GarageBand.app - 381.7 MB
GarageBand copy.app - 373.2 MB

iMovie.app - 695.3 MB
iMovie copy.app - 635.4 MB

Install Xcode.app - 1.81 GB
Install Xcode copy.app - 1.57 GB

Agora, sou novo no Mac e, depois que percebi esse problema de discrepância no tamanho do arquivo, descobri que os arquivos .app não são realmente arquivos - eles são realmente diretórios, mas o Finder os exibe como se fossem arquivos. Por isso, pensei que talvez o processo de duplicação não copiasse todo o conteúdo do diretório .app original, o que explicava a diferença de "tamanho do arquivo". Mas baixei e instalei o DeltaWalker, que é uma ferramenta de comparação de arquivos / pastas, e o DeltaWalker disse que os diretórios .app duplicados eram exatamente iguais aos diretórios originais .app. Portanto, o processo de duplicação funcionou perfeitamente e, portanto, parece ser um problema com o tamanho dos arquivos de relatórios do Finder.

Também verifiquei os tamanhos dos diretórios no Terminal, usando o comando "du", e isso também mostra discrepâncias nos tamanhos entre os diretórios original e duplicado:

du -k /Applications/GarageBand.app/
212868  /Applications/GarageBand.app/

du -k /Applications/GarageBand\ copy.app/
397880  /Applications/GarageBand copy.app/

du -k /Applications/iMovie.app/
629644  /Applications/iMovie.app/

du -k /Applications/iMovie\ copy.app/
700500  /Applications/iMovie copy.app/

du -k /Applications/Install\ Xcode.app/
1771864 /Applications/Install Xcode.app/

du -k /Applications/Install\ Xcode\ copy.app/
1772228 /Applications/Install Xcode copy.app/

Além disso, não são apenas os diretórios .app. Eu dupliquei meu diretório / Developer / Library, e aqui está o que du disse:

du -k /Developer/Library/
320784  /Developer/Library/

du -k /Developer/Library\ copy/
399868  /Developer/Library copy/

Então, alguém pode explicar por que o Mac OS X parece não informar os tamanhos de diretório corretamente? É um bug (difícil de acreditar em algo tão simples) ou estou sentindo falta de algo (sendo um novo usuário do Mac)?

(Estou executando o Mac OS X Lion 10.7.2)

UPDATE em resposta a elofturtle:

O mais estranho disso é que o Finder não tem consistência. Acabei de fazer 2 duplicatas do GarageBand.app e depois fiz 2 duplicatas de uma das duplicatas. O Finder exibe todas as duplicatas com um tamanho diferente:

GarageBand.app - 381.7 MB
GarageBand copy.app - 357.6 MB (duplicate of GarageBand.app)
GarageBand copy 2.app - 353.9 MB (duplicate of GarageBand.app)
GarageBand copy 3.app - 378.2 MB (duplicate of GarageBand copy 2.app)
GarageBand copy 4.app - 329.1 MB (duplicate of GarageBand copy 2.app)

Observe também que "GarageBand copy 3.app" é maior que "GarageBand copy 2.app", enquanto "GarageBand copy 4.app" é menor que "GarageBand copy 2.app". Isso deve ser um bug no Finder.

Aqui está o que "du -k" diz sobre todos eles:

212868  /Applications/GarageBand.app/
397880  /Applications/GarageBand copy.app/
397880  /Applications/GarageBand copy 2.app/
397880  /Applications/GarageBand copy 3.app/
397880  /Applications/GarageBand copy 4.app/

Pelo menos, diz que todas as duplicatas têm o mesmo tamanho, mas não têm o mesmo tamanho que o original.

As diferenças vieram de diferentes razões: maneiras diferentes de contar, ferramentas diferentes, compactação e o que parece ser um bug.

A primeira diferença de tamanho que você vê parece ser um bug no Finder . Os tamanhos de arquivo mostrados pelo Finder são de alguma forma calculados 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, mostra o tamanho acinzentado nas janelas do Finder, cinza, o que significa que o Finder sabe que o conteúdo foi alterado desde o último cálculo de tamanho, mas ainda não o recalculou .

A única maneira que encontrei para fazê-lo recalcular corretamente o tamanho é excluindo o .DS_Storearquivo na pasta Application, fechando o Finder (no Monitor de atividades, por exemplo) e reiniciando-o novamente (no ícone do Dock). Se você não excluir o .DS_Storearquivo, ele ainda permanecerá acinzentado. Talvez esperar algum tempo (horas, dias, reinicializar, ...) faça com que o Finder faça isso sozinho.

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

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

Então, vamos considerar a duferramenta. No começo, pensei que a diferença que vemos poderia ser explicada pela diferença entre os tamanhos lógico e físico dos itens que estão sendo copiados. Tamanho lógico é o tamanho real do item, significando que cada bit de informação que ele contém é somado. Tamanho físico é o tamanho do item no disco, onde cada bit de informação é gravado em um setor de 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 até 4096 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 segmento . O tamanho lógico pode ser maior no caso de arquivos esparsos , mas o HFS + parece não suportar esse recurso.

dumostra apenas o tamanho físico (e você pode dizer o que é um BLOCKSIZE). Você pode ver que o tamanho relatado por dué sempre maior (ou, excepcionalmente, o mesmo) que o original. Isso ocorre devido à fragmentação do sistema de arquivos e do espaço em disco. Quando você copia um arquivo (na verdade, aqui vários arquivos, como um Aplicativo é um diretório), novos setores estão sendo alocados no disco e, à medida que a fragmentação ocorre , o número de blocos usados ​​geralmente é maior que o do item original. Algumas pessoas chamam isso de File Slack .

Agora, de volta ao Finder. Se você abrir a janela obter informações dos aplicativos duplicados, verá que o Finder está realmente relatando o tamanho lógico e o físico do item selecionado. O que faz sentido. Você poderá comparar o tamanho físico relatado pelo Finder e o tamanho relatado duse fizer um pouco de matemática.

Por que fazer algumas contas? Como o Finder mostra os tamanhos de arquivo em kB, MB ou GB, onde os dureporta em kiB, MiB ou GiB. Esses são os prefixos binários da IEC que devem ser usados ​​para calcular e exibir unidades de informação digital.

Mas, na verdade, não tenho certeza se o File Slack está envolvido aqui, há algo mais. Os volumes HFS + permitem compactação , feita de forma transparente, e a Apple usa isso para os itens originais instalados pelo sistema operacional. Em seguida, 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 você quiser manter a compactação nesses arquivos, precisará usar o dittocomando em vez de cpou qualquer ação do Finder. Isso é explicado nesta revisão .

Aqui está o resultado da cópia do iTunes.app usando as diferentes técnicas. Você verá que o mesmo torna o aplicativo exatamente do mesmo tamanho, preservando a compactação, onde cpnão. E você pode até remover o binário do arco de que não precisa e reduzir o tamanho inteiro):

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 resposta em meu post complementar .

É uma falha / bug horrível no OS X. A maneira mais fácil de ver isso é duplicar um pacote grande de aplicativos, mostrar o conteúdo e excluir um grande arquivo de dentro. O espaço não se recuperará. O arquivo ainda é enorme. Por exemplo, se você possui um pacote de aplicativos de 3,5 GB, mostra o conteúdo e remove 3 GB, agora você deve ter um aplicativo com o tamanho de arquivo de 500 MB. Você não vai. Ainda será de 3,5 GB.

Isso é basicamente um palpite, mas vejo duas possibilidades:

1. Alguns dados foram excluídos, mas não desalocados no original, e isso não é copiado. No entanto, ele aparece em algumas pesquisas de uso de disco, mas não em outros (parâmetros diferentes fornecidos para o du ou o que o OS X usa internamente).
2. Alguns dados são vinculados ao local original e isso afeta o tamanho percebido em diferentes ferramentas.

Se (1) você provavelmente deverá obter resultados diferentes fazendo uma terceira cópia e comparando as cópias.

Primeiro, você precisa estar ciente de que os arquivos .app do Mac são, de fato , Diretórios , e não binários compilados, como arquivos .exe do Windows. O Finder apenas oculta esse fato para pastas chamadas * .app.

por exemplo (do Terminal)

# cd /Applications/Calculator.app
# ls
Contents/

Tenho certeza de que o que está acontecendo é que o Finder / Get Info está usando uma heurística não muito inteligente para calcular o tamanho da pasta .app. Isso significa que não é necessário enumerar todas as subpastas e arquivos e adicionar todos esses tamanhos.

Meu palpite é que a estimativa da cópia está correta porque o OSX recentemente teve que inspecionar todos os arquivos contidos nela quando você fez a cópia, enquanto no original, o OSX pode nunca ter sido necessário (por exemplo, com instalações de fábrica)

Eu tive esse problema com o meu diretório pessoal depois que o mudei para um disco rígido interno depois de instalar o Yosemite no SSD. Ao usar 'Obter informações', ele relatou um tamanho incorreto de apenas 8 GB, embora tenha mostrado o tamanho correto de 240 GB na barra de status do Finder. Corrigi-o clicando em Obter informações na pasta Usuários, que calculou corretamente e corrigiu o tamanho incorreto relatado pelo Diretório base.