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

[headbulb]

your right you have not used os X there are two kind of users in os X admins and regular users the admins can use sudo while the users may not be able to sudo or with certain resrictions

the root acount is disabled as in the password is * meaning none which means you can't login with it

HeadBulb

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.

Ahem

[benh57]

Three hours before this other guy: benh57 Here are your recent submissions to Slashdot, and their status within the system: * 2001-11-04 02:29:02 Apple's iTunes2 Update Wipes Drives (articles,apple) (rejected) Summary: * rejected (1)

Re:The big mistake here...

[benh57]

Sorry, wrong. The iTunes2 installer updates the Disc Recording framework which is part of the system. Thus it DOES need an installer - and root privs.

Re:How the hell does this happen?

[Apotsy]

It happens because Apple uses the .pax archive format inside of its "pkg" files. This format is known to be a risky choice because it can do very "destructive" updates if not used very, very, very carefully as seen in this case.....

Yes, pax is a complete piece of crap. The good folks over Stepwise warned about problems with it a long time ago (scroll down to the heading "Installer.app"). Apple blithely went on using pax anyway.

Perhaps after this disaster, Apple will finally realize they should maybe start using something more robust for their packaging system on X.

It is worth noting that the Mac OS 9 version of the iTunes 2.0 installer (yes, they are still updating the Mac OS 9 version of iTunes) did not exhibit the problem, as it doesn't use pax. It uses Apple's old "tome" installer archive format instead.

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.

Re:Liability

[jeti]

Here's a quote from the discussion at macnn:

<quote>
Aha! It seems that this is not quite correct for some jurisdictions. They could be liable per the EULA, last line of implied warranty section:

"SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES OR LIMITATIONS ON APPLICABLE STATUTORY RIGHTS OF A CONSUMER, SO THE ABOVE EXCLUSION AND LIMITATIONS MAY NOT APPLY TO YOU. "
</quote>

(BTW: You definitely got the uppercase right. Obviously it is used to make the EULAs even more unreadable.)

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

iTunes.app IS a folder

[Anonymous Coward]

Yes, you should always quote variables in shell scripts, but given that iTunes.app is a single file, there is no point to the -r (recursive remove, for removing everything below a directory) option to rm.

But iTunes.app IS a folder, under MacOSX a .app is a folder with some extra flags, a .plist, and the actual executable code inside (among other things).