I committed a new version to SVN tonight, and it is one that I have been doing a lot of testing on (minus a couple of very minor tweaks that do not seem to be killing anything). I have bumped it to 1.6b1 because I have started a change that I have wanted to do for a long time: I am starting the dismantling of the folders system. Before people get scared about this, I am only dipping our collective toe in this water so far, and plan on making a few changes in InstaUp2Date to support this. For the moment the change is restricted to three new flags available for use:
[code]
-I Use dmg at this path as the installer disk.
-J Mount dmg at this path during installs.
-K Use folder as a source for updates, call multiple time in order for multiple folders.
[/code]
If you do not use these flags then InstaDMG will continue to operate just like it used to. But i will forewarn people that when I finally get around to version 2.0 the old behavior will be gone (but I will probably add in a migration tool to help you along).

A little more specifically:
– The ‘I’ (as in ‘capital eye’) option lets you choose the “primary installer disk”, that is a DMG of a MacOS X Installer DVD. Because you can no specify things directly we are no longer tied to using specific names to pick out the right disk. So as long as you are using this flag you can name the dmg whatever you would like. If you use this flag it implies the ‘-J’ flag as well, so discs will not be mounted from the BaseOS folder automatically.

– The ‘J’ flag should be used if you are going to be using any supporting disks that should be mounted durring the run (such as the extra discs for FinalCut Pro… and no I don’t have a copy to check that it works, so you are on your own there). These disks will be mounted in a Finder-visible way, so they will pop up on the desktop.

– The ‘K’ option can be used to specify, in order, the folders you would like to include as update folders. If this flag is not used it implies:
[code]-K ./InstallerFiles/BaseUpdates -K ./InstallerFiles/CustomPKG[/code]
Beyond the uses I want to put this to in InstaUp2Date (updates to follow when I have the chance), this should also be a boon to consultants who want to have multiple clients share the same InstaDMG folder, but have separate updates, but who (inexplicably) don’t want to use InstaUp2Date… and yes, I have specific (Scandinavian) people in mind with this comment.

Also notable in this update is that I have finally stared really testing with using a second disk as a scratch space (I went out and bought an external RAID for this testing). I discovered a bug in the 10.6 installer with this case, and so if you are building a cached base install that part of the install will happen on your local disk. I am working up the bug to submit to Apple, but I think this one is in the actual 10.6.0 installer pkg, so we are probably stuck with it. I am seeing more than a 20% speedup in runs (after the first run) by moving the cache file to an external FireWire800 RAID (that maxes out the FW bus). I expect that a second internal disk might to about that, and internal RAIDs would improve on that. I would strongly encourage anyone using the ‘-t’ switch to make sure that the target is HFS+ (case preserving but insensitive), and strongly suspect that you will get nasty results trying this on an XSan.

I plan on this version being the one I will be presenting with at Macworld, so would really appreciate people trying it out in the next couple of days, and reporting success/failure on it. If you get failure I will ask you to send me (off-list) the log files for that run so that I can look at it (kuehn [dot] karl @ gmail [dot] com). But if it works (I think it will) please just post the following lines from the output (they are separated), if you used the -t option (and what it was pointing at), and your computer Model Identifier (found in System Profiler, look like: iMac8,1)

[code]
InstaDMG version 1.6b1 (svn revision: 237)
Host OS version: 10.6.2
Target OS version: 10.6 (10A432)
[/code]