So, the other night I’m working on my sweet new Power Mac G5 (okay, not one of the new new sweet dual-core units, but it’s no slouch, k?). I’ve got a friend, Patch, from the New Zealand trip that is stationed in Iraq. He took a DV camera with him and shot a lot of footage and he asked me to convert it to DVD for him so I’m doing that. I pull all the stuff into iMovie HD, add a title and chapters and then export it to iDVD. Rather than burning a DVD right now (although that wouldn’t have made a difference at all) I burn it to a disc image so I can burn more than one copy later. Everything worked just fine and was hunky dorie. Well, it was hunky dorie until Cort came over to do some work on her project and needed to burn a DVD with iDVD. It goes, previews just fine and burns without an error. We put it in a DVD player to make sure it’s all kosher and we’re surprised that the audio was not the one we just previewed, but instead it was the audio from the DVD I made for Patch. “Okay, somehow it’s reading from the other project, we’ll just move it to an external disk and unmount it” I think. We do that and try again. Same, a new coaster for my table. Stupidly I try something else and burn again. Same. Now I’m really scratching my head. Of course had I just looked in the Apple Knowledge Base after the first time I would have found out that the iDVD dev team doesn’t know squat about well behaved applications on multi-user systems. I take that back, they might, but from this incredibly dumb bug they sure don’t show it. The other thing that kills me is that this is something easily verified in QA processes. The things of
note here are:
When writing temp files to a system shared by multiple users each temp file needs to have at least the username in it to make it not block or stomp other users use of the system.
If you write temp files that are only around for one phase of processing then you remove them when that process is done (especially if the permissions are restrictive enough that another user can’t remove the file which is good in this case as you don’t want another user interrupting a phase of processing that does rely on said file).
iDVD does it’s preview based on quicktimes (refrencing to iMovie I’m guessing) and then has to encode the audio for burning. It should give an error when it can’t open the file to store the newly encoded audio rather than failing silently!
There is a point release (x.0.1) of iDVD from the version 5 release. How this bug is still around is a mystery. If it was introduced in 5.0.1 then I’m going to be shocked.
Now I have to figure out how to fix it in case I’m not around to be admin and clean it out for another user.