Hace bastante tiempo, noté que incluso si creo archivos DMG desde el mismo directorio, con los mismos archivos, etc., los resultados son siempre diferentes. No solo su tamaño es ~ 15 bytes más corto / más largo entre sí, sino que sus sumas de verificación SHA (y sus contenidos, cuando se ven desde el editor HEX) difieren drásticamente. Solo por curiosidad, he creado 5 archivos DMG sin cifrar comprimidos de la misma carpeta que contienen nada más que un solo archivo de texto. Los resultados son:

0.dmg | tamaño - 26204 bytes, suma de comprobación - 5ba9ba0ee4d8ec5ba4718f1b491baf31c2c4e642
1.dmg | tamaño - 26221 bytes, suma de comprobación - a86d76f6c07ee5a81c0aefb31b6fd40ef787ebd5
2.dmg | tamaño - 26235 bytes, suma de comprobación - a31f4cf29e4e2858b7ac63c82574499200d81108
3.dmg | tamaño - 26209 bytes, suma de comprobación - f3c19414279b6d6b94b90341453906e4a69e28dd
4.dmg | tamaño - 26 217 bytes, suma de comprobación - 9603c0334125762fc7908343e3ee400e038fe779

He estado navegando en Internet con la esperanza de encontrar algo sobre el "aleatorizador de datos en APFS", pero ... obviamente no pude encontrar una sola cosa, y además, no mucha gente sabía realmente sobre esta "característica". ¿Hay alguna información al respecto?

Estoy ejecutando macOS 10.12.6, los archivos DMG se crearon con Disk Utility, pero obtengo los mismos resultados con hdiutil.

— L0W_P1X3L
fuente

Necesitamos más información para proporcionar una respuesta adecuada. Sin embargo, sospecho que la fuente en realidad está cambiando, aunque solo sea en metadatos (marcas de tiempo de acceso, etc.), y que el DMG refleja estos cambios. ¿Has intentado probar con diferentes sistemas de archivos en el contenedor?

— jsejcksn

Si los bytes cambiaron, los datos cambiaron, lo que significa que la suma de verificación cambiará. Sospecho que jsejcksn tiene razón y se están cambiando los metadatos (15 bytes es muy pequeño). Intente comprimir los datos primero, luego cree dmg de eso y vea si los datos y las sumas de verificación permanecen iguales, o proteja el directorio antes de crear el dmg.

— pretensiones Guy

Establecí el sistema de archivos en RW y creé 2 archivos DMG, y uno de ellos es 40 bytes más grande que el segundo. Tal vez tengas razón, y los metadatos de ese archivo de texto cambien (¿"último abierto", tal vez?) Intentaré escribir un script simple que muestre la información del archivo, y espero que aparezca algún resultado útil.

— L0W_P1X3L

También bloquearé el archivo, como Christian sugirió.

— L0W_P1X3L

@ L0W_P1X3L: Tendría que examinar la estructura detallada de la imagen del disco para encontrar qué cambió. Esto será mucho más fácil si no está comprimido. Pero, en general, no debe esperar que los mismos archivos generen exactamente la misma imagen de disco: el formato de imagen de disco puede incluir (o depender) de mucha información extraña que probablemente sea realmente difícil de controlar. No estoy seguro de por qué desea obtener la misma imagen de disco varias veces, pero sea cual sea su objetivo real, debe encontrar una forma diferente de lograrlo.

— Gordon Davisson

Las copias de una existente dmgserán idénticas pero los dmgarchivos creados por separado no lo serán.

Efectivamente garantizado para diferir

El formato Apple Disk Image .dmg garantiza efectivamente que no habrá dos imágenes de disco idénticas bit por bit. La igualdad entre imágenes de disco que contienen el mismo contenido no es un requisito práctico del formato.

UUID dentro del `0x6B6F6C79`/ `koly`Bloque

Dentro del dmgformato de archivo está la kolyestructura . Esta estructura incluye un SegmentID de tipo uuid_t. Este es un Identificador Universalmente Único ( UUID ) de 128 bits . El identificador SegmentID solo asegurará que cada dmgarchivo difiera en más de un bit.

El uso de HFSleuth en la imagen de disco de iTunes 11.0 muestra el 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

En el ejemplo anterior, la línea Segment UUID: 626f726e-7743259b-6086eb93-4b42fb65es un identificador universalmente único incrustado en la imagen del disco.

Diferencias de un bit y funciones hash

Una diferencia en un bit debería dar como resultado un cambio del 50% o más en una salida de función hash criptográfica, como SHA-2.

El uso de un UUID dentro de la estructura no es para garantizar que cada imagen de disco sea única, sino para facilitar la identificación de segmentos dentro de la imagen de disco. Que un UUID proporcione propiedades de unicidad más allá del alcance de la imagen del disco es un subproducto del uso del UUID.

— Graham Miln
fuente

He creado varios archivos DMG desde la misma carpeta: ¿la suma de comprobación es diferente en cada uno?

Efectivamente garantizado para diferir

UUID dentro del 0x6B6F6C79/ kolyBloque

Diferencias de un bit y funciones hash

UUID dentro del `0x6B6F6C79`/ `koly`Bloque