Today we're ran into a rather obscure situation. Rosyna has created a bz2-compressed DMG image for the new beta of the next major update to FontCard, and when I went to download it, I've noticed that Safari downloads it as "fontcard-xxx.dmg.bz2". Needless to say, it tried to expand the bz2 file upon downloading, and then failed miserably on mounting the expanded DMG file with this error:

"WTF?", I thought. The file name in the URL was ending with "dmg" and not "dmg.bz2". Yes, the data inside of the DMG is compressed using bz2, but nobody should care about that.

So I tried to download the same file using FireFox, and all went just fine: the image downloaded, the file name never changed, and it mounted as it should. I've looked at the response our server been sending, and it was:

Content-Type: application/octet-stream

So what I am guessing is that Safari tries to guess the file type when it's not forcibly defined by the Content-Type; in this particular case, it looked in the file and noticed it is most likely a bz2 archive, so it safely appended the .bz2 extension to the file and continued the download, resulting in the hiatus described above.

So, we've made a tiny change to our .htaccess file, and guess what? Now all DMGs (including the one I just had problems with) download just fine. This also possibly explains why some of our users were having random issues with the DMG images they've downloaded. Perhaps in some cases Safari decided it's a zip archive (since we used to prepare our DMGs compressed with zip), expanding it before passing to the diskutil, making it fail in the end.

So, if you serve DMGs off your hosting, take a note on that. Luckily, the fix is simple (assuming your web host uses Apache):

Open or create a .htaccess file in the root of your Web directory, and put the following line in:

AddType application/x-apple-diskimage dmg

This instructs Apache to forcibly tell the visitors that files ending with "dmg" has a content type of application/x-apple-diskimage, which makes Safari behave as it should: skip the "guessing" part and pass the image where it belongs.

I'd like to say thanks to Mark Rowe for telling us the "right" MIME type. ;)