1

My company ships a package containing several Qt-based MacOS/X GUI applications; the package ships as a .dmg file, and "installation" consists of double-clicking the .dmg icon, then dragging one or more application icons to where he wants to keep them (e.g. to his own Applications folder).

This works fine, but the .dmg file is rather large (e.g. 40+MB) and I'd like to reduce its size if possible, in order to reduce the time it takes to download it. One thing I notice is that the applications in the package all have a significant number of large files in common (Qt libraries, graphic resource files, etc), and that currently we are including a separate copy of each of these files inside the blah.app/Contents folder of each included application -- presumably this is what makes the .dmg file so large.

So my question is, is there any way to modify the .dmg so that it doesn't need to include several copies of these files, and thus isn't so big? Ideally I'd like to do this without requiring the user to run a special installer program, and without causing any of the applications to break if the user moves them to different (or unexpected) folders, or deletes any of them.

It seems like this would be an ideal application for hard-links -- i.e. prepare the input to the .dmg file such that one application contains the actual files, and the other applications contain hard-links to those files, so that after the user unpacks the applications from the .dmg file the files remain logically independent of each other (and in particular application B won't stop working if the user moves or deletes application A). But AFAICT MacOS/X doesn't support hard-links [edit: to directories] for applications that aren't named Time Machine. :^(

Jeremy Friesner
  • 70,199
  • 15
  • 131
  • 234
  • Could you elaborate in what sense “MacOS/X doesn't support hard-links”? I just typed “ln somefile samefile” in a terminal and I don't see in what sense hardlinks are not supported. – Pascal Cuoq Aug 13 '12 at 18:34
  • Ah, perhaps it is just hard-links to directories that MacOS/X doesn't support. From Wikipedia: "To prevent endless recursion, most modern operating systems don't allow hard links on directories. In addition, hard links on directories would lead to inconsistency on parent directory entries. A notable exception to this is Mac OS X v10.5 (Leopard) and newer, which use hard links on directories for the Time Machine backup mechanism only." Still, IIRC hard links to files get turned into separate copies as part of the .dmg creation process, and thus don't reduce the .dmg size. – Jeremy Friesner Aug 13 '12 at 18:42
  • 1
    Then one option would be to make the DMG read-write and to create the sharing on the DMG, perhaps before filling it up completely (keep some unique files to copy on the DMG as last step, after having hard-linked identical files onto one another manually). – Pascal Cuoq Aug 13 '12 at 18:46
  • Hmm, after running a test it looks like I am wrong about hdiutil's behavior regarding hard-file-links ... a directory with a large file and a hardlink to that file does *not* create a larger .dmg file than one with just the large file alone. So maybe I have my solution :^) ... that would work well for large files (like Qt libraries) but it would be a bit awkward for directories with many small files. – Jeremy Friesner Aug 13 '12 at 18:49
  • 1
    If you copy hardlinked files to the image, then you may get them physically copied multiple times, but if you copy one file and then create a hardlink in the image it should work. OsX supports hardlinks and softlinks at the filesystem level (Finder and the standard open/save dialogs sometimes have problems with softlinks, especially softlinks to directories. Also some applications may have problems with softlinks. Hardlinks however are ok). Hardlinks to directories are supported in the sense that they work if you know how to create them, but AFAIK there's no documented API to do it. – Analog File Aug 13 '12 at 21:01
  • FWIW this morning I created a little program that scans my autobuild script's output directory for duplicate files and replaces the "extra files" with hardlinks to the first one found. I have my autobuild script run this program just before calling hdiutil to create the .dmg file. This appears to work well -- it reduces the .dmg file's size from ~40MB to ~30MB. – Jeremy Friesner Aug 13 '12 at 22:08

1 Answers1

2

(it feels vaguely immoral to answer my own question, but since I came to a solution I'll do it anyway, rather than leave the question hanging open)

The solution is to replace the duplicate files with hard-links to the first-encountered file, before running hdiutil to create the .dmg file. I did this using a simple C++ program that I wrote for the purpose (just because I'm stubborn that way), but there are also a number of freeware programs such as freedup that will do this for you. I didn't try them, but I imagine they all work fine.

Jeremy Friesner
  • 70,199
  • 15
  • 131
  • 234