Image conversion and shadow file

I’ve downloaded the trial version of DropDMG and overall I’m pleased with the UI and the functionality.

However, there is one essential thing I couldn’t figure out:

The Mac terminal tool hdiutil has a great feature called ‘shadow file’. I use this quite often to apply changes to compressed images, i.e. mounting the image with a shadow file, applying changes to the image content and then converting the image with the shadow file to a new compressed image (hdiutil convert … <image.dmg> -shadow -o <newimage.dmg>).

In DropDMG I figured out how to mount an image with a shadow file, but I’m missing the second part, that is converting the image with the modified shadow file to a new image. DropDMG converts the image but ignores the shadow file. I also tried to drag the image to DropDMG with the option key down, but I can’t see any optional setting for this. I even tried to drag the image file and the shadow file to DropDMG but it doesn’t recognize the shadow file as belonging to the image file.

Can you enlighten me?

Have you tried dragging the mounted disk image (i.e. the white disk icon) onto DropDMG?

No, I didn’t. Thank you! (This isn’t in the manual, isn’t it?)

Just a suggestion: Maybe it would be a good idea to write the converted image to the original location, instead of moving it to the desktop? (It took me several attempts till I got the brilliant idea to have a look on my (seldom visible) desktop to discover all the converted image files there :wink:

Thanks for your help.

Another question: For the zlib compressed images DropDMG apparently uses level 9. Is there a way / hidden preference to change this to level 1 (the hdiutil default). The reason why I’m asking is that zip level 1 seems to be noticeably faster with large images, and for maxed out compression there is always bz2.

Not yet. :slight_smile:

The logic here is that the mounted disk image is a volume, and volumes appear on the desktop. So DropDMG uses the desktop if you had “Next to Source” selected.

DropDMG could potentially try to figure out which disk image file is backing the volume—if, in fact, it’s not a physical volume, and if the disk image file is local. I’m not sure whether this would be worth it or less confusing, overall.

I’ll see if I can add this as an esoteric preference. I’m kind of surprised that you’re noticing a big difference, as I thought all the variants of zlib were pretty fast on modern hardware.

I just made a test run with zlib level 1 vs 9 and the difference is even more drastic than I subjectively perceived:
I created an UDZO image of a 587MB Devonthink database with mixed content. (Hardware: MacBook Air late 2010 with 2.13 GHz Intel Core 2 Duo.)
zlib level 1 took 41s, level 9 took 78s; that’s almost twice as long!

I made the image in 2 steps (first an UDRW image then convert to UDZO) because it is faster, via a KM-bash script.

cd "$KMVAR_filePath"
hdiutil create -format UDRW -srcdir "$KMVAR_fileName" "$KMVAR_fileName".tmp.dmg
hdiutil convert "$KMVAR_fileName".tmp.dmg -format UDZO -imagekey zlib-level=9 -o "$KMVAR_fileName".dmg
rm "$KMVAR_fileName".tmp.dmg

With the ‘normal’ 1-step approach (creating directly the UDZO) I got 71s vs 144s which reflects a similar ratio.

Maybe with a faster CPU the ratio would be a bit more in favor of zlib 9 (?)

EDIT: The difference in final image size is virtually negligible: 442 vs 452MB

EDIT 2:

For curiosity I did the same test (the 2-steps variant) on my MacBook Pro (early 2008) with a 2.6GHz Intel Core 2 Duo and a ‘mechanical’ HDD (the MacBook Air from the previous test has flash storage). As expected the ratio is less dramatical: zlib1 83s vs zlib9 119s. This is due to the slower disk write speed which lowers the percentage of pure computing time in total time. Nevertheless it’s still a ratio of 1:1.4.

This is possible with DropDMG 3.2.