DropDMG DMGs failing to mount

We are evaluating DropDMG to purchase for our office.

We are on 10.4.8 and are creating DMGs from upto 7GB Photoshop (PSD) files.

When we create DMGs, they open up fine on the machine that created them.

However, our other office (whom we are ftp’ing the dmg file to) cannot open the DMG files. They get an error “The following disk image failed to mount”. They have tried it on machines running 10.3 and 10.4.1.

We really like this tool, but this is a showstopper for us.

Any suggestions?

First, I’d check the format that you’re using. For example, the “.dmg bzip2-compressed” format can only be mounted on Mac OS X 10.4 and later.

Second, something may be going wrong with your FTP, either during upload or download. Try creating a smaller DMG for testing purposes. Upload it and then download it back to your same Mac and see if you can open it.

You could also use the “md5” command on the command-line to check whether the uploaded and downloaded files have the same checksum.

Hi Michael,

Thanks for your reply.

To rule out ftp corruption, we tried a small test file (44k) and used email.

We created a file with bzip2 compression on a 10.4.7 Dual G5.

On a 10.4.8 Dual G5, we get a ‘file unrecognized’ error when we double click the dmg file.

We checked in the terminal and there are a whole bunch of bz* binaries on the system.

When we create a dmg with Z-lib compression it works fine on the 10.4.8 machine.

We like bzip2 because of the small files it creates.

Any ideas?

I’m not clear on your test. Are you saying that the small file didn’t work via e-mail or FTP? If the small file doesn’t work, perhaps you could e-mail it to me at dropdmg@c-command.com for testing.

Did the name of the unrecognized file still end with .dmg? Did you try getting info on it with DropDMG?

Which FTP program are you using, and is there a way you can set it not to post-process or decode the files that it downloads? Internally BZip2-compressed disk images and standard Unix BZip2 archives look similar. (They both have the same “magic number” at the beginning of the file.) So it’s possible that your FTP program is noticing this and trying to be helpful by expanding what it thinks is a BZip2 archive, but is in fact corrupting the disk image.

One workaround would be to use BZip2 but tell DropDMG to add GZip encoding. This would protect the disk image inside a .gz wrapper.

We emailed a small 44k dmg file and got the same errors as the large dmg file that we had previously ftp’d. Both files are bzip2 format with encoding=none.

I am emailing you a copy of the small test file.

Did the name of the unrecognized file still end with .dmg?

Yes

Which FTP program are you using, and is there a way you can set it not to post-process or decode the files that it downloads?

We are using Cyberduck FTP at each office on the upload and download.

Internally BZip2-compressed disk images and standard Unix BZip2 archives look similar. (They both have the same “magic number” at the beginning of the file.) So it’s possible that your FTP program is noticing this and trying to be helpful by expanding what it thinks is a BZip2 archive, but is in fact corrupting the disk image.

One workaround would be to use BZip2 but tell DropDMG to add GZip encoding. This would protect the disk image inside a .gz wrapper.

OK … we will try this too.

Thanks

I have tried your test file on an Intel Mac running 10.4.8 and on a PowerPC Mac running 10.4, 10.4.1, and 10.4.8, and it worked successfully on all of them. (I don’t have a G5, however.) Will continue discussing this with you via e-mail to try to figure out what’s going wrong, but at this point I don’t think it’s a problem with the .dmg file.

We tried encoding the file with gzip as you suggested and it seems to fixed the issue. We’ll continue testing it out and let you know. Thanks.