InstaDMG freeze

[sketch]

v1.6b2

Trying to build my 10.6 image and it seems to get stuck on “Closing programs that have opened files on the disk”

What’s up? Should I just comment this out for the moment so I can get my work done?

[Allister Banks]

Hey There,

Please post the revision number inside the instadmg.bash script, and the relevant part of your debug .log from that run. I can’t say with absolute certainty, but my gut reaction is that is not to be messed with, unless you don’t want to resulting build to have screwy links that there are specific dependencies in place for. Sorry to be pessimistic without hard facts, but it is expected behavior that that is the most time consuming part of the process.

Allister

[larkost]

Unfortunately this is one of those places where it is going to take a bit of time since it has to search the whole volume for links, then check to make sure they are not pointing off-disk (this is a boo-boo that Apple makes in the iLife installer).

I do have a couple of ideas for speeding it up, but have not had the time to implement them. If someone wants to take a whack at doing them:

1) Write a Foundation (C, maybe with a little Obj-C) tool that would watch all of the file creation events on the target disk and log a list of sym-links that could then be gone through much faster at the end of the process. This is probably going to be the fastest method as it only burns a little processor power right when the system is already working on the disk catalog (we are much more bound by I/O than processor). Then we have to run this while the process is going (a bit tricky with the bash script, but doable).

2) Write a Carbon tool that uses Apple’s FSCatalogSearch method to grab the disk catalog in chunks and process it. This is probably going to be twice as fast as the current method, possibly evne more than that. For a little reference there are some [url http://www.cocoadev.com/index.pl?NSDirectoryEnumerator%5Dnumbers on CocoaDev that gave me this idea.

[Author]

Posts