Disk images suck: An examination of why, and of the alternatives

2007-05-13 08:25:15 UTC

Here is a rundown of every file format you can use to distribute your software, along with their advantages and disadvantages. They are listed in ascending order of effectiveness.

In case you’re wondering, 7-zip and StuffIt X are not listed here because nobody has decompressors for them. I wrote this list for the context of software distribution; the days of saying “You will need StuffIt Expander to open this file” are long over.

Disk image

Advantage:

Sandboxes the application: If it won’t work from the disk image, it probably sucks

Disadvantage:

Confuses the average user; they typically run the application from the disk image, then encounter problems when they try to delete the image file or (much later) run a Sparkle update


Back in March, an Adium user had a problem trying to perform the Sparkle update. It gave her an error:

“Update Error! Adium does not have permission to write to the application's directory! Are you running off a disk image? If not, ask your system administrator for help.”

This wouldn’t be so bad, except that she didn’t know what a disk image was, so she assumed that she was not running Adium from the disk image (I imagine she thought something like “surely I’d know what that was if I was using one”). She looked up the troubleshooting instructions in the Adium help (good), then critically misunderstood them (bad) with the result that she moved her Adium 2.0 folder out of the Application Support folder. (Don’t ask me to explain it. I don’t know, either.)

All this ultimately resulted from the fact that average users, including her, don’t recognize a disk image when they see it. They don’t expect a file to act as a drive.

The same non-obvious nature results in other problems: specifically, the error message “The operation cannot be completed because ‘SurfWriter-1.0.dmg’ is in use”. This occurs when the user tries to delete the disk image file without unmounting it first. Users who encounter this message end up contacting us (usually asking “how do i uninstall it”). This is only natural, because who would expect that a file is mounted, or that a file can be in use in another file?

It was then that I realized that disk images are not as great for the average user as I had previously believed.

You may be thinking “well, just put a background image with an arrow to an Applications folder”. We did that. It didn’t help this user.

The stories I heard from other developers suggest that people in general zero in on the application they want to use, without paying attention to anything else (e.g., arrows, help text, or symlinks). Besides, the questions I hear from the users via the feedback list suggest that users see the disk image window and think the application is already installed—they aren’t looking for or expecting installation instructions, so your big arrow means nothing to them.

I suspect that installers are partly to blame for that: I don’t know about Windows, but on Mac OS, installers would always open the folder containing the freshly-installed application, so that you could use it right away. I suspect that users mistake the disk image window for a freshly-installed-folder window.

Anyway, one solution to the tunnel-vision problem would be a “DRAG THIS OVER HERE” message in a big font—but that’s no good, because you can’t have localized background images. You’d have to pick one language, and hope that all your users know it, but anybody who doesn’t know the language you chose wouldn’t benefit from your nice obnoxiously big text. (On the other hand, this provides a second reason for unilingual builds: One disk image per language, with both the background and the application localized in that language only. Hmmmm.)

Another solution is a runtime check whether the app is running from the disk image. You’ll have to be careful with wording here, though—you need to be 100% sure that you’re running from a disk image, and write the alert text accordingly. There can be no vacillation like in the Adium alert box (which vacillates because it’s caused by a simple permission failure, not an actual search for the disk image nature); it must be a statement, not a question. And of course, you must tell the user the remedy (copy the app, then run the copy, then eject the disk image file and never mount it again).

One last point: bzip2 compression (-format UDBZ) requires Tiger. Your disk image won’t mount on any earlier version of the operating system; your users will think it’s corrupt, since that’s what the error message suggests, and they’ll contact you with that assumption. This probably doesn’t matter anymore, since the Omni Group’s software-update statistics say that 98.4% of users are on Tiger (as of 2007-05-12), but if you still support users of earlier OS versions, you need to use zlib compression (-format UDZO) instead.

Tarball

Advantages:

Smaller than disk images; unpacks into a folder or bare application

Disadvantage:

Safari mishandles bzip2′d tarballs pretty spectacularly; one must gzip one’s tarballs to avoid that problem, but then one loses out on yummy bzip compression


Safari, for some reason, saves a bzip2′d tarball as “foo.tbz.tar”, even though it is still a tbz. Unpacking it results in a tar archive named “foo.tbz”, followed by the folder that the tar archive exists to hold. So the actual unpacking behavior works as expected, but it badly screws up the filenames.

This all works correctly with tgz, but of course you can’t use gzip and have bzip2 compression.

Zip archive

Advantages:

Unpacks into a folder or bare application; can be created from the Finder

Disadvantage:

Bigger than anything else


Zip archives are the easiest to create, because you can simply right-click on the contents and choose “Create Archive of SurfWriter.app”. Unfortunately, the compression ratio is just not there; I consider zip files obsolete for this reason. You should be optimizing for your users’ download time, not your own compression time.

Internet-enabled disk image

Advantage:

Unpacks into a folder or bare application for the average user (Safari with “Open Safe Files” turned on); perfectly normal for everybody else

Disadvantages:

Won’t work the same way twice (when the user goes to unpack it the second time, it behaves as a perfectly normal disk image, with the attendant confusing UI); hard to create; unpacks slowly


This is the best of both worlds. The average user uses Safari and has “Open Safe Files” turned on; in this case, Safari will unpack the disk image just as if it were a tarball or zip archive. The sort of person who turns “Open Safe Files” off, or uses a different browser, is also the sort of person who can handle a normal disk image, and will indeed be handling it because that’s how the disk image behaves in those cases. The extremely-rare exceptions can be handled by the aforementioned runtime check.

They’re the hardest to create because you need to use a Terminal command (hdiutil internet-enable SurfWriter-1.0.dmg) to set the internet-enabled bit on the image. Dear Lazyweb: Please make a contextual menu item that generates an internet-enabled UDBZ disk image directly from a folder in one step, the same way I can make a zip archive in one step. (Michael Tsai, in a comment, says that his $20 DropDMG utility can do this, with Automator‘s help.)

Another disadvantage is that a disk image, internet-enabled or otherwise, takes much longer to process than a zip archive. I think this is because of the verification step, but the user won’t care. I think people will put up with it for most archives, but if your archive is huge (let’s say over 50 MiB), you may want to switch to a zip or tarball to save time. Of course, you’ll be sacrificing part of your bandwidth bill for that. (Thanks to Sven-S. Porst for bringing this up in another comment.)

Also, the format notes (UDBZ vs UDZO) for disk image above apply to internet-enabled disk images as well. Just in case you were wondering.

I bring this up because, having in mind my objections above to disk images, I released EasyMD5 as a zip archive. I did it this way because EasyMD5 is targeted at Adium users (specifically, those who have problems downloading Adium); experience has proven that I can’t assume that an Adium user will know how to deal with disk images. Everybody knows how to handle zip archives (hello, Chris!), so I made it a zip archive.

I hadn’t yet done the study of file sizes that I did and published yesterday. Now that I have, later today, I’ll replace the zip archive with an internet-enabled disk image.

UPDATE 11:37: Added mentions of Paul Kim’s proposal of a runtime check for the disk image nature, and clarified the Lazyweb request.

UPDATE 20:47: Updated to include comments from Sven-S. Porst and Michael Tsai.

13 Responses to “Disk images suck: An examination of why, and of the alternatives”

  1. David Smith Says:

    Internet Enabled disk images also don’t work properly in all browsers, which can be a bit awkward (my parents, for example, are Camino users).

  2. Peter Hosey Says:

    How don’t they work properly in other browsers? (Aside from being just like non-internet-enabled images.)

  3. Simone Manganelli Says:

    DropDMG is a nice piece of software that’ll make an internet-enabled disk image from a folder, but it costs $20 and isn’t a contextual menu item. But it’s worth mentioning anyway.

  4. ssp Says:

    I had my 2.71 words to say on this in the past. And the bottom line isn’t clear at all. In particular I found that the size advantage of disk images can range from being very small – around 5% say – to quite large – I think I’ve seen up to 1/3, depending on the data you have.

    From a user-friendliness POV, though, I think zip always wins these days. If only because Safari will decompress the archives almost instantaneously while even an internet enabled disk image requires quite lengthy processing with the mounting, copying and unmounting that has to be done. You can even see the mounted image while this happens which can easily lead to unintended confusion as well.

    I guess this is the price we have to pay for Apple choosing the very ‘compatible’ zip format for us.

  5. Michael Tsai Says:

    Simone: You can setup a configuration in DropDMG with the options that you want (such as Internet enabled), then create an Automator workflow that uses that DropDMG configuration, and finally save the workflow as a contextual menu item plug-in.

  6. Simone Manganelli Says:

    Michael: I stand corrected. So you can. :)

  7. Peter Hosey Says:

    ssp and Michael: I’ve updated the post to include your comments. Thanks!

  8. ssp Says:

    Ah, well I forgot half of what I wanted to say: I meant to post two links (below) the upshot of which is that you want to have a line like

    alias dmg ‘hdiutil create -ov -format UDZO -layout NONE -imagekey zlib-level=9 -fs ‘HFS+’ -srcfolder \!:1 \!:2.dmg; hdiutil internet-enable -yes \!:2.dmg’

    in your .tcshrc (or use UDBZ in there if you don’t need X.3 compatibility, of course). Turning this into something equivalent for bash or other shell hell or putting it into an Automator workflow is left as an exercise to the reader.

    http://earthlingsoft.net/ssp/blog/2003/11/xcode
    http://earthlingsoft.net/ssp/blog/2007/04/software_distribution

  9. Peter Hosey Says:

    I find the zsh equivalent far more straightforward:

    function dmg { hdiutil create -ov -format UDBZ -layout NONE -srcdir $1 $2.dmg && hdiutil internet-enable $2.dmg }

    Should work in bash, too, but I haven’t tested it.

    I hadn’t known about -layout NONE before. Does that help anything?

  10. ssp Says:

    When I played with all options of the hdiutil command a few years back it seemd to decrease the size of the disk image slightly. At least in the tests I did back then I could beat pretty much any other feasible compression method which is why we went with disk images as we didn’t have a lot of bandwidth to waste then.

  11. David Smith Says:

    In response to comment 2, just that they behave like normal disk images.

  12. Martin Redington Says:

    You should be able to serve up localized disk images, by inspecting the language settings of incoming http requests, and configuring your webserver to send the appopriate image, or an english fallback if you don’t have a version for the users language.

    This would actually be pretty sweet.

  13. Peter Hosey Says:

    Martin: Agreed.

    However, some users don’t use English as their system language, even if they know English and accept it in web responses. For these users, you should have your Download link go to a page that redirects to the disk image for the automatically-chosen language, and offers direct links to the disk images in all the other languages.

Leave a Reply

Do not delete the second sentence.