Muito tempo atrás eu notei que mesmo se eu criar arquivos DMG do mesmo diretório, com os mesmos arquivos e etc, os resultados serão sempre diferentes. Não apenas seu tamanho é menor que 15 bytes mais curto, mas suas somas de verificação SHA (e seu conteúdo, quando visualizadas pelo editor HEX) diferem drasticamente. Apenas por curiosidade, eu criei 5 arquivos DMG não criptografados compactados da mesma pasta contendo apenas um único arquivo de texto. Os resultados são:

0.mg | tamanho - 26 204 bytes, soma de verificação - 5ba9ba0ee4d8ec5ba4718f1b491baf31c2c4e642
1.dmg | tamanho - 26 221 bytes, soma de verificação - a86d76f6c07ee5a81c0aefb31b6fd40ef787ebd5
2.dmg | tamanho - 26 235 bytes, soma de verificação - a31f4cf29e4e2858b7ac63c82574499200d81108
3.dmg | tamanho - 26 209 bytes, soma de verificação - f3c19414279b6d6b94b90341453906e4a69e28dd
4.dmg | tamanho - 26 217 bytes, soma de verificação - 9603c0334125762fc7908343e3ee400e038fe779

Eu tenho navegado na internet na esperança de encontrar algo sobre o "randomizador de dados no APFS", mas ... obviamente não consegui encontrar nada, e além disso, poucas pessoas realmente sabiam sobre esse "recurso". Existe alguma informação sobre isso?

Estou executando o macOS 10.12.6, os arquivos DMG foram criados usando o Utilitário de Disco, mas obtenho os mesmos resultados com o hdiutil.

— L0W_P1X3L
fonte

Precisamos de mais informações para fornecer uma resposta adequada. No entanto, suspeito que a fonte esteja realmente mudando, mesmo que apenas em metadados (timestamps de acesso, etc.), e que o DMG reflita essas mudanças. Você tentou testar com diferentes sistemas de arquivos no contêiner?

— jsejcksn

Se os bytes forem alterados, os dados serão alterados, o que significa que a soma de verificação será alterada. Eu suspeito que o jsejcksn está certo e os metadados estão sendo alterados (15 bytes é muito pequeno). Tente zipar os dados primeiro, então crie um dmg disso e veja se os dados e checksums permanecem os mesmos, ou protegendo o diretório antes de criar o dmg.

— Unassuming Guy

Eu configurei o sistema de arquivos para o RW e criei 2 arquivos DMG, e um deles é 40 bytes maior que o segundo. Talvez você esteja certo, e os metadados desse arquivo de texto mudem ("pela última vez", talvez?) Eu tentarei escrever um script simples que mostrará as informações do arquivo, e esperamos que algum resultado útil apareça.

— L0W_P1X3L

Eu também vou bloquear o arquivo, como Christian sugeriu.

— L0W_P1X3L

@ L0W_P1X3L: Você teria que examinar a estrutura detalhada da imagem do disco para encontrar o que mudou. Isso será muito mais fácil se for descompactado. Mas, em geral, você não deve esperar que os mesmos arquivos gerem exatamente a mesma imagem de disco - o formato da imagem do disco pode incluir (ou depender) de muitas informações estranhas que provavelmente são realmente difíceis de controlar. Não sei por que você deseja obter a mesma imagem de disco várias vezes, mas qualquer que seja seu objetivo real, você deve encontrar uma maneira diferente de realizá-la.

— Gordon Davisson

Cópias de um existente dmg será idêntico, mas criado separadamente dmg arquivos não.

Efetivamente garantido para diferir

o Imagem de disco da Apple .dmg O formato garante efetivamente que duas imagens de disco não serão bit por bit idênticas. Igualdade entre imagens de disco contendo o mesmo conteúdo não é um requisito prático do formato.

UUID dentro do `0x6B6F6C79` / `koly` Quadra

Dentro do dmg formato de arquivo é o koly estrutura . Essa estrutura inclui um SegmentID do tipo uuid_t. Este é um identificador exclusivo universal de 128 bits ( UUID ). O identificador de SegmentID sozinho garantirá que cada dmg arquivo difere em mais de um bit.

Usando HFSleuth na imagem de disco do iTunes 11.0 mostra o UUID incorporado:

HFSleuth> ver
Verbose output is on
HFSleuth> fs iTunes11.dmg
KOLY header found at 200363895:
    UDIF version 4, Header Size: 512
    Flags:1
    Rsrc fork: None
    Data fork: from 0, spanning 200307220 bytes
    XML plist: from 200307220, spanning 56675 bytes (to 200363895)
    Segment #: 1, Count: 1
    Segment UUID: 626f726e-7743259b-6086eb93-4b42fb65
    Running Data fork offset 0
    Sectors: 1022244

No exemplo acima, a linha Segment UUID: 626f726e-7743259b-6086eb93-4b42fb65 é um identificador universalmente exclusivo incorporado na imagem de disco.

Diferenças de um bit e funções hash

Uma diferença em um bit deve resultar em 50% ou mais de alteração em uma saída de função hash criptográfica, como SHA-2.

O uso de um UUID dentro da estrutura não é para garantir que cada imagem de disco seja única, mas para facilitar a identificação do segmento dentro da imagem do disco. Que um UUID fornece propriedades de exclusividade além do escopo da imagem de disco é um subproduto do uso do UUID.

— Graham Miln
fonte

Eu criei vários arquivos DMG da mesma pasta - a soma de verificação é diferente em cada um deles.

Efetivamente garantido para diferir

UUID dentro do 0x6B6F6C79 / koly Quadra

Diferenças de um bit e funções hash

UUID dentro do `0x6B6F6C79` / `koly` Quadra