iTunes2.0.1 released

Nov 02, '01 11:30:02PM

Contributed by: robg

Apple has now re-released iTunes2 for OS X, in the form of a new iTunes 2.0.1, available on the iTunes2 download page. For those of you who might have grabbed the original installer, delete it now. It had a serious error with the installer script that could wipe your hard drive in certain circumstances.

The short version of what Apple appears to have changed in this new installer? Any reference that used to look like this

rm -rf $2Applications/iTunes.app 2< /dev/null
now looks like this
rm -rf "$2Applications/iTunes.app" 2< /dev/null
The addition of the quotation marks takes care of any issues regarding drives with spaces in their filenames. In addition, the file lengths on "iTunes.bom" and "iTunes.pax.gz" have both changed, indicating that there were additional changes made behind the scenes. I haven't bothered top expand and compare the two .pax archives; at this point, suffice it to say that Apple made a bad mistake, realized it, and acted quickly (for a large corporation) to fix the problem. This, of course, is little solace for those who were affected.

A detailed explanation of the problem with the earlier installer script is available if you read the rest of this article...

Here's what I was theorizing earlier today...

If you downloaded the iTunes2 installer and have not yet installed it, I would highly recommend that you do not install it! Apple has pulled the installer due to a bug in the script. Thanks to a tip in an email about the cause (spaces in volume names), I went digging into the package installer and think I found the source of the problem. The following code is in a file called 'preflight' inside the iTunes.pkg installer (in Contents/Resources):

# if iTunes application currently exists, delete it
if [ -e $2Applications/iTunes.app ] ; then
rm -rf $2Applications/iTunes.app 2< /dev/null
fi
So what's the problem? If your volumes have spaces and are named similarly (let's say "Disk", "Disk 1", and "Disk 2"), then this bug could bite you. The '$2' variable that's passed in contains the path to your selected iTunes installation destination. In our example, let's assume it was headed for "Disk 1". So '$2' should contain /Volumes/Disk\ 1 (notice the backslash for the space). However, if it instead contained /Volumes/Disk 1, then the "rm -rf" command would execute TWICE. It would look like this:
rm -rf /Volumes/Disk 1/Applications/iTunes.app 2< /dev/null
One of the commands (the second half, 'rm -rf 1/Applications/iTunes.app') would probably not do anything, since the path is invalid. The second command, though, could be brutal. 'rm -rf /Volumes/Disk' would delete the entire volume 'Disk' used in this example.

I can't see how the "$2" variable is built, so this is all conjecture based on the evidence and looking at the "preflight" file. Obviously, there's an issue with the installer, since Apple has now pulled it ... but if you grabbed it already, I would highly recommend you do not use it, even if you don't appear to meet the criteria listed above. Just wait for a new installer from Apple, and keep your data safe!

UPDATE: Now that I have the new installer, it's quite easy to see what changed. The 'preflight' script now looks like this:
# if iTunes application currently exists, delete it
if [ -e "$2Applications/iTunes.app" ] ; then
rm -rf "$2Applications/iTunes.app" 2< /dev/null
fi
The quotation marks take care of the issues with space in drive names, and there were also some apparent changes to a few of the files in the iTunes bundle.

Comments (30)


Mac OS X Hints
http://hints.macworld.com/article.php?story=2001110223300292