Oops... looks like apple didn't do their homework, with the initial release of their iTunes installer!
Apple has this notice on their iTunes site...
An important note for those who have downloaded iTunes 2.0 for Mac OS X:
Apple has identified an installer issue with iTunes 2.0 for Mac OS X that affects a limited number of systems running Mac OS X with multiple volumes (drives or partitions) mounted. For those systems, running the iTunes 2.0 installer can result in loss of user data.
While this error is highly unlikely to affect most users, Apple strongly advises that anyone who has downloaded the 2.0 version of iTunes for Mac OS X, as well as anyone who has a beta version of iTunes 2.0 for Mac OS X, immediately remove the iTunes.pkg installer file from their system.
A new version that corrects this issue, iTunes 2.0.1 for Mac OS X, is now available from this page. Users who have already installed iTunes 2.0 without incident do not need to reinstall iTunes 2.0.1, but they should still immediately remove the 2.0 installer file from their system. This issue does not affect users of iTunes 2.0 for Mac OS 9.
Click the ..Read More link for more technical details...
Found this in the MacNN forum and on Slashdot, explains the problem quite nicely!!!
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
Thanks to a tip in an email about the cause of the problem (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:
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.
For those that had a problem, do you meet all the following criteria?
1. Did not delete iTunes 1.1
2. Had multiple volumes
3. Had similarly named volumes with spaces in their names
Any replies could help determine if this is, indeed, the cause of the problem.
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!
Apple has this notice on their iTunes site...
An important note for those who have downloaded iTunes 2.0 for Mac OS X:
Click the ..Read More link for more technical details...Apple has identified an installer issue with iTunes 2.0 for Mac OS X that affects a limited number of systems running Mac OS X with multiple volumes (drives or partitions) mounted. For those systems, running the iTunes 2.0 installer can result in loss of user data.
While this error is highly unlikely to affect most users, Apple strongly advises that anyone who has downloaded the 2.0 version of iTunes for Mac OS X, as well as anyone who has a beta version of iTunes 2.0 for Mac OS X, immediately remove the iTunes.pkg installer file from their system.
A new version that corrects this issue, iTunes 2.0.1 for Mac OS X, is now available from this page. Users who have already installed iTunes 2.0 without incident do not need to reinstall iTunes 2.0.1, but they should still immediately remove the 2.0 installer file from their system. This issue does not affect users of iTunes 2.0 for Mac OS 9.
Found this in the MacNN forum and on Slashdot, explains the problem quite nicely!!!
The original installer script has the lines
# if iTunes application currently exists, delete it
while the replacement (2.0.1) hasif [ -e $2Applications/iTunes.app ] ; then
rm -rf $2Applications/iTunes.app 2> /dev/null
fi
Thanks to a tip in an email about the cause of the problem (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
# if iTunes application currently exists, delete it
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:if [ -e $2Applications/iTunes.app ] ; then
rm -rf $2Applications/iTunes.app 2< /dev/null
fi
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.For those that had a problem, do you meet all the following criteria?
1. Did not delete iTunes 1.1
Any replies could help determine if this is, indeed, the cause of the problem.2. Had multiple volumes
3. Had similarly named volumes with spaces in their names
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!