~1MB difference in 1.7.12 DMG file sizes

[tinyapps]

Thanks so much for crafting and sharing Bit Slicer over all these years.

For version 1.7.12, there is a ~1MB difference in DMG file sizes between the zgcoder.net-hosted version ("Bit Slicer.dmg", 18067112 bytes, f0d4be8275d2fc7c886ea8b8bfd7a8b3fb5ec97d SHA-1 hash) and the GitHub-hosted version ("Bit.Slicer.dmg", 17033030 bytes, a9350c7501b25a61c5dc05dfd4d97c163b62eacb SHA-1 hash).

Mounting the DMGs reveals "Bit Slicer.dmg" from zgcoder.net includes a .fseventsd directory, but that only accounts for 156 bytes.

The "Bit Slicer.app" directories of the mounted DMGs are identical according to diff -r, Beyond Compare, and this neat Python script (found here).

And yet, creating an uncompressed tar archive or a compressed zip archive of the identical "Bit Slicer.app" directories results in slightly different file sizes (68535808 vs. 68492288 bytes and 20655340 vs. 20616000 respectively); the same test on other Internet-downloaded apps did not display this anomaly.

Can anyone please help shed some light on either the ~1MB DMG file size difference or how two reportedly identical directories can produce archives of different sizes?

[AlexanderOMara]

Looks like the two DMG files are also signed on different days (check with codesign -vvd Bit.Slice.dmg). No idea why.

When I copy the apps out, I see different xattrs on the app (check with xattr -x -l 'Bit Slicer.app'), which might account for the difference in archive size if the xattrs/resource-fork are archived. Again, no idea why they differ.

The actual app and all the data forks on all the files appear to be the same.

[tinyapps]

Thank you very much for your fast reply, AlexanderOMara.

Does the Finder ignore xattrs when reporting file size? "Bit Slicer.app" from both DMG files are reported as being 65,077,929 bytes. But the slight difference in xattr data cannot account even for the slight discrepancy in archive sizes.

[zorgiepoo]

They are compressed differently (you can tell if you use the file command on the archives). The one on my website uses lzfse / APFS and the one on GitHub uses bzip2 / APFS. I forgot to update the one on GitHub, so I will probably do that soon and leave this issue open for that. bzip2 is more of a "deprecated" compression method; while it has a smaller file size, decompression speed is generally significantly slower. To use LZMA (smaller but slower than lzfse) would require me shipping to only macOS 10.15+ users (it is significantly better than bzip2 but not always a better trade-off over lzfse). Differences in extended attributes are unfortunately incidental.

[tinyapps]

Thanks so much for the explanation, zorgiepoo.

Especially appreciate the tip about using file to find the different compression algorithms - neat!

I'm still puzzled about the second question; how two seemingly-identical app directories (down to the last byte!) can generate two differently-sized archives using the same technique. But of course that is probably a question for a different forum - sorry to trouble you!

[zorgiepoo]

And yet, creating an uncompressed tar archive or a compressed zip archive of the identical "Bit Slicer.app" directories results in slightly different file sizes (68535808 vs. 68492288 bytes and 20655340 vs. 20616000 respectively); the same test on other Internet-downloaded apps did not display this anomaly

Try creating the archives by passing flags that do not preserve any extended attributes (xattrs) or other metadata. Metadata like extended attributes can easily be added or differ for a number of reasons.

If I Get Info on the two app bundles in Finder inside the different disk images, they are reported to be both 65,077,929 bytes.

(file doesn't tell you what filesystem the disk image is formatted as, but you can tell if you diskutil list after you mount a dmg).

I don't use it, but if you want to know something else neat, but apfs / HFS+ also support compression on the filesystem level. If you make a copy of the app using ditto --hfsCompression for example, you will see the copy takes up significantly less space on disk with the compression being tucked into hidden extended attributes. I think apps installed from the App Store usually use this type of compression.

[tinyapps]

Thank you for that pointer, zorgiepoo.

The tar man page listed four promising options: --no-acls, --no-fflags, --no-mac-metadata, and --no-xattrs.

After a bit of trial and error, I found that identical tar archives could be produced by combining --no-xattrs and --no-mac-metadata (despite the tar man page stating that --no-mac-metadata was for "x mode only"), so long as I did not change the app filenames before archiving.

Thanks also for the note on filesystem compression - had more or less forgotten about it since the DriveSpace era ;-)