[switch-nz]

Part of #47 (second of the three PRs agreed: LZFSE, DMG, AFF4). #47 stays open for AFF4.

What changes for examiners

• DMG (Apple UDIF) images open like any other disk: partitions and filesystems inside are found by the existing readers. Chunk types read: raw, zero-fill, zlib, bzip2, LZMA and LZFSE.
• A chunk that will not decompress, or decompresses to the wrong length, reads as zeros and is reported; ranges the block tables do not cover read as zeros and are reported.
• Refused with a reason and advice (never shown partly): encrypted images, multi-segment images, images with ADC chunks or unknown chunk types, overlapping or out-of-file chunks, oversize compressed chunks, a missing or damaged property list/table. .sparseimage (sprs) is named and refused as a different format.
• DMG has no signature at the start, so it is detected by the koly trailer in the last 512 bytes together with version 4 and header size 512; a file that merely ends in "koly" stays raw. .dmg is now offered when browsing for images.

Verification

• tests/imagebuild_dmg.py builds images from the published UDIF layout (trailer, plist blkx, mish tables); 23 tests cover every chunk kind, reads across chunks/partitions/gaps, one real LZFSE stream from Apple's encoder, a FAT volume inside a DMG, refusals, detection edge cases and random damage.
• DMG fuzz target added (2500 cases, no findings). Also opened a DMG through the real server: the FAT16 volume inside is found.
• Full suite 1321 tests OK (14 skipped), smoke passes.
• Synthetic only. No DMG written by Apple's tools (hdiutil) was available, and I know of no independent DMG reader to cross-check against, so the builder and reader share my reading of the layout. Real images still need checking; ROADMAP and CHANGELOG say so.

🤖 Generated with Claude Code

https://claude.ai/code/session_017DPjyZZHvaivtvJ3N4hZhz

---

Generated by Claude Code

[switch-nz]

CI note: one job failed, Smoke test (windows-latest, Python 3.9), on two smoke checks about legacy-case index move and compacting a case (timeout: timed out, then HTTP 400). The other 27 jobs passed, including the unit tests on Windows and the smoke test on the other OS/Python combinations, and the same checks passed on main for the previous merge (run 254). Neither check touches disk-image opening, and this PR passes them locally. That job's setup step also took about 75 seconds, so it looks like a slow runner timing out; the second failure follows the first. I've re-run the failed job once; if it fails again I'll treat it as real and dig in.

---

Generated by Claude Code