10.6 DMG corruption?

[jessepeterson]

Sounds far fetched, right? This is a weird one. Perhaps someone could shine some light. On a 10.6 box, do this:

cd /tmp

curl -RLO https://raw.github.com/kcrawford/dockutil/master/scripts/dockutil

hdiutil create -format UDZO -imagekey zlib-level=3 -srcfolder dockutil dockutil3.dmg

hdiutil create -format UDZO -imagekey zlib-level=4 -srcfolder dockutil dockutil4.dmg

Then try and open dockutil3.dmg. Should open fine:

$ hdiutil attach dockutil3.dmg 
expected   CRC32 $19A07431
/dev/disk2              Apple_partition_scheme          
/dev/disk2s1            Apple_partition_map             
/dev/disk2s2            Apple_HFS                       /Volumes/dockutil

Looks good. But then try and open dockutil4.dmg. Does it work for you? This is what I get:

$ hdiutil attach dockutil4.dmg 
hdiutil: attach failed - corrupt image

Am I missing something here? The zlib-level seemed to be added in #14. Seems to work okay on a 10.9 machine, but on 10.6 something's up. This prevents my recipe from working on 10.6.

Bug in hdiutil create with this one example, perhaps? I've been using DmgCreator for a while with no issues. Odd.

[jessepeterson]

Slight difference with the files: lacking the com.apple.diskimages.recentcksum xattr.

$ ls -la@ dock*
-rw-r--r--  1 jesse  wheel  30412 Jan 25 18:00 dockutil
-rw-r--r--@ 1 jesse  wheel  19453 Jan 25 18:01 dockutil3.dmg
    com.apple.FinderInfo       32 
    com.apple.ResourceFork   1650 
    com.apple.diskimages.recentcksum       51 
-rw-r--r--@ 1 jesse  wheel  16976 Jan 25 18:01 dockutil4.dmg
    com.apple.FinderInfo       32 
    com.apple.ResourceFork   1650 

[gregneagle]

Not sure that tells us anything; checksums are calculated when a diskimage is mounted; since dockutil4.dmg can't be mounted, no checksum is stored for it...

On Jan 25, 2014, at 6:16 PM, Jesse Peterson notifications@github.com wrote:

Slight difference with the files: lacking the com.apple.diskimages.recentcksum xattr.

$ ls -la@ dock*
-rw-r--r-- 1 jesse wheel 30412 Jan 25 18:00 dockutil
-rw-r--r--@ 1 jesse wheel 19453 Jan 25 18:01 dockutil3.dmg
com.apple.FinderInfo 32
com.apple.ResourceFork 1650
com.apple.diskimages.recentcksum 51
-rw-r--r--@ 1 jesse wheel 16976 Jan 25 18:01 dockutil4.dmg
com.apple.FinderInfo 32
com.apple.ResourceFork 1650
—
Reply to this email directly or view it on GitHub.

[jessepeterson]

Makes sense. So you can duplicate it?

[gregneagle]

I don't have access to a 10.6 machine until Monday.

Sent from my iPhone

On Jan 25, 2014, at 6:21 PM, Jesse Peterson notifications@github.com wrote:

Makes sense. So you can duplicate it?

—
Reply to this email directly or view it on GitHub.

[jessepeterson]

Just thought I'd also add: zlib levels 1-3 work fine. 4-9 give corrupt DMGs. Something about the content of that dockutil download seems to do it. An empty file or file with different content doesn't seem to produce the corrupt DMG. Very weird.

[timsutton]

This is indeed weird. I modified your commands to pull mcxToProfile:

cd /tmp
curl -RLO https://raw.github.com/timsutton/mcxToProfile/master/mcxToProfile.py
hdiutil create -format UDZO -imagekey zlib-level=3 -srcfolder mcxToProfile.py mcxToProfile3.dmg
hdiutil create -format UDZO -imagekey zlib-level=4 -srcfolder mcxToProfile.py mcxToProfile4.dmg

I also tried with Reposado's repo_sync so as to pick a file that's at least as large as dockutil. I can't seem to reproduce this with anything other than dockutil.

[gregneagle]

Given that this affects a single thing on an old OS (10.6), I'm not motivated to to anything about it. But if Jesse wants to add a new (optional) zlib_compression_level input variable to DMGCreator, that seems reasonable.

[jessepeterson]

I don't do my autopkg runs on 10.6 (any more). I do a little bit of testing on 10.6 with autopkg, but I'm not particularly motivated to fix it either. How about an OS check in DMGCreator that bumps it down to zlib_compression if on 10.6?

[timsutton]

I think just making the compression level an optional input variable makes more sense. In 99% of cases nobody will touch it but if it happens to somehow cause issues then someone can override it, like in your case.

[timsutton]

(just saw the commit after posting this)

[gregneagle]

I dislike the hard-coding based on OS revision. It addresses a single problem we've seen, but there is no guarantee it will address other similar problems. Better to make it a variable the recipe author can tweak as needed. If you want to set the default value conditionally based on OS version, I'm OK with that.

[jessepeterson]

Fair enough. I figured that'd be the case - why I didn't submit a PR. ;)

[jessepeterson]

I'm comfortable closing this issue now that awareness has been raised. Thanks folks!

[timsutton]

See the new dmg_zlib_level option that will be in 0.3.0: e896643