iTunes 2.0 Installer Deletes Hard Drives

Cheviot writes: "It seems Apple's new iTunes 2 installer deletes the contents of users' hard drives if the drives have been partitioned. I personally lost more than 100gb of data. More information is available at Apples Discussions board. (registration required). Apple has pulled the installer, but for hundreds, if not thousands, the damage is already done." The iTunes download page has a nice warning about the problem. Ouch.

Comments

Good Read

[Kira-Baka]

http://newforums.macnn.com/cgi-bin/ultimatebb.cgi? ubb=get_topic&f=46&t=000865

It has some info about causes and solutions...

Nature of the bug

[HalfFlat]

From the discussion on the Apple discussion web site, the nature of the bug is as follows.

The original installer script has the lines

# if iTunes application currently exists, delete it
if [ -e $2Applications/iTunes.app ] ; then
rm -rf $2Applications/iTunes.app 2> /dev/null
fi

while the replacement (2.0.1) has

# if iTunes application currently exists, delete it
if [ -e "$2Applications/iTunes.app" ] ; then
rm -rf "$2Applications/iTunes.app" 2> /dev/null
fi

In these scripts, $2 corresponds to the volume on which iTunes is to be installed, and will be of the form /Volumes/name-of-volume.

For those unfamiliar with Bourne shell variable expansion, if $2 has spaces in it, the argument to the rm command in the first version of the script will expand to more than one word, and rm will try and delete both of these. The -rf tells rm to delete everything down recursively and not complain about it.

This is particularly a problem on the Mac, where filenames and volume names often have spaces in them., even at the beginning of the name. If one had multiple partitions mounted in /Volumes, and the one on which iTunes was to be installed was called, say, ' OS X', then the rm command would expand to

rm -rf /Volumes/ OS X/Applications/iTunes.app 2> /dev/null

and would then try and delete everything under /Volumes. This is clearly bad.

The second version, by including quotes around the argument, fixes the problem. The quotes force the argument to be treated as a single argument after variable expansion.

Traditionally, people have been super careful about destructive operations and shell expansions. I don't think I've ever seen something like this written in a 3rd party script before, in fact (let alone from the OS vendor!). This could well be an example of programmers new to a Unix-like platform still getting used to the Unix way of doing things, and getting bitten as a result.