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

Already updated

[Anonymous Coward]

Apple has already put iTunes 2.0.1 that purportedly takes care of the problem:

http://www.apple.com/itunes/download/

Corrected version 2.01 already posted by Apple.

[sakusha]

Come on now, Apple jumped on this one, it was only reported by a couple of people, and they corrected the problem almost immediately. This problem only came to light today, and they have a fix out the same day. I downloaded the new 2.01 version, installed with no problems.

quote

[Jotham]

the bug is apparently caused by the lack of quote marks in the install script.

Apparently it only strikes if you 1) havn't uninstalled iTunes first 2) have multiple partitions and 3) have spaces in the name of your partitions

This from MacSlash (posted by Graff as AC):

Well, there is a fixed installer up now. Looks like the following change was made to the "Preflight" file inside the "iTunes.pkg" package:

old version:

#!/bin/sh

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

exit 0

new version:

#!/bin/sh

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

exit 0

As you can see, they basically placed quotes around the file paths so that any characters such as spaces in path names would not mess up the rm command. So easy, and yet even the best of us forget to do it at times. That's one of the things about the command line - lots of power when used properly, but also many powerful ways to mess everything up.

- Graff

Re:quote

[ecampbel]

Quotes get evaluated first and only once, and then variable substitutions happen, so having quotes in your drive name will not cause problems.
For example (in csh):
% setenv foo \"
% echo $foo
"
% echo "some quoted text:$foo"
some quoted text:"

Everything within quotes is passed as one argument to the echo command, and the fact that $foo contains a quote character doesn't cause any problems. If the quotes were evaluated after variable substitutions, an unmatched quote error would have been reported in the last example.

Re:Users in OS X

[IronChef]

You can enable root login in the NetInfoManager. When you do, it asks you to put in a root password, and then you can log in or su to root if you want.

bogus shell quoting rules

[mj6798]

This is really a problem in how the Bourne shell handles variables. Lots of UNIX scripts fail when file names contain spaces, which is why most people don't use spaces in file names.

The folks at Bell Labs seem to have realized that this was a mistake, which is why the "rc" shell (also available for Linux) now handles things differently: variable substitution does not result in re-tokenizing.

Re:bogus shell quoting rules

[dangermouse]

This is really a problem in how the Bourne shell handles variables.

Okay, there have been multiple posts to this effect, and they're all wrong.

Sorry, but this is not a "problem". The shell operates on lists of words. A variable is assumed to contain a list under most circumstances. List elements (words) are separated by an Internal Field Separater character, defined by $IFS.

Every single one of my Bourne-compatible shells' man pages explicitly state the types of expansion that are employed generally (including word splitting) and provide a short list of exceptions.

This is expected, normal, useful behavior. And it's easily handled, as you can simply wrap any variable in quotes if you don't want it to be tokenized as multiple parameters. If it's something you can't cope with, that's a shame, but don't act as though it's some flaw in the shell... it's there on purpose, and with good reason.

the REAL code, and how this did happen

[Anonymous Coward]

In the installer is a small shell script to remove any old copies of iTunes. It contained the following line of code:

rm -rf $2Applications/iTunes.app 2
where "$2" is the name of the drive iTunes is being installed on.

The problem is, since the pathname is not in quotes, if the drive name has a space, and there are other drives named similarly then the installer will delete the similarly named drive (for instance if your drives are: "Disk", "Disk 1", and Disk 2" and you install on "Disk 1" then the command will become "rm -rf Disk 1/Applications/iTunes.app 2

The new updated version of the installer replaced that line of code with:

rm -rf "$2Applications/iTunes.app" 2
so things should work fine now.

Possible Fix...

[DragonPup]

Andrew Welch of Ambrosia Software posted a method that MIGHT work on recovering the files here. Basically sometimes the installer, according to Andrew, just messes with file permissions and visability, not actually deleting them.

I didn't test this because iTunes didn't mess up my 5 partitions, thankfully.

-Henry