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

How the hell does this happen?

[dimator]

Well, here's the pseudo-code:


if(installDrive->hasEnoughSpace()){
return startInstall(instalDrive);
} else {
installDrive->formatRecklessly();
return startInstall(installDrive);
}


Hard-to-spot bug, actually.

Re:How the hell does this happen?

[Jace of Fuse!]

No.

Sorry.

Extensive testing went out of style around the mid 90's.

Oh -- and actually writting REALLY good code, that's been out of style since at LEAST the 80's.

I blame colleges for letting so many graduates think that they are instantly coders.

Real coders are born, not made.

And anybody who got into computers for the money, and not the thrill of writing code -- well -- they're worse than lame. And they probably use AOL.

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.

Re:How the hell does this happen?

[cshotton]

Apple has had a greatly diminished QA organization over the years. I think this is due in large part to the serious turnover the company experienced in late '97 - early '98. Nearly every engineer that worked on the original Mac OS left during this time. The Developer Technical Support organization was gutted, and quality assurance became an exercise in million monkey button pounding.

Having been the author of a 3rd party product bundled and shipped on Apple hardware, I can tell you that the extent of their QA process doesn't go much beyond making sure the software installs and runs on an out of the box system, followed by some mediocre mashing of buttons and menus. They really don't understand or implement the concept of actually testing on live, deployed, end user (like) systems. They have racks of off the shelf machines with standard software loads. If they install and run and stay up over the weekend, it's shippable.

We would get reams and reams of complaints about how dialog boxes weren't formatted just so, etc., but their QA department never caught a single defect that most would consider a bug in the code. And there were certainly bugs to catch.

This is a chronic problem that most commercial software houses have. They tend to put junior people with little product experience in the QA organizations and assume that by acting like reasonably competent users, they will somehow uncover logic flaws, data errors, and other engineering foibles. The only time I ever saw QA done right was on a NASA project with life critical software systems. The project was staffed with the very most senior engineers running the QA department and all of the junior engineers were slinging code.

It was up to the gray beards to make sure the junior guys wrote code that was to spec, integrated properly, handled all of the possible input scenarios, and actually performed in a live environment. These senior guys were also the architects of the system, so they knew what the software was supposed to do, how it was supposed to be constructed, and what it should take to break it. I doubt that 1 in 100 commercial shops today have an engineer working in the QA department that actually understands the code they are testing down to the module level. When was the las time you saw a QA guy in a design session, learning about how the system he's going to test is going to be architected?

This is so far from the current practice in commercial industry today as to almost have the flavor of a fairy tale. Apple's no different than any number of other companies who are rushing to ship software on a too short schedule. They pay lip service to QA and rely on their early adopter users to find any lingering problems. In this case, they totally dicked over their customers by not doing their job. However, they're only partially to blame since I think the development of iTunes is still done by Casady and Greene under contract to Apple. I'd be surprised if they weren't ultimately responsible for creating everything, including the installer. Regardless, Apple should have tested this before sticking it on-line on a Saturday night.

Re:How the hell does this happen?

[Anonymous Coward]

You raise some interesting points about testing in industry.

I would like to offer some comments as a tester, myself.

Yes, testing is not generally done correctly or particularly rigorously. There have been some common factors in my experience:
1) Code not developed to Specification. This is by far the most common. I can't count how many times I've been told "But this is a better way to implement XXXX."
2) Poor unit testing of software.
3) Delay in testing due to: delays in development, delays in configuration/delivery of environment. (Don't get me wrong, this is really a management issue. I have NEVER been on a project that has let the testing deadline slip even though the entry criteria were slipped - sometimes even by 3 months! It is ridiculous to not adjust testing periods.)
4) Unrealistic expectations or deadlines by PM/managers.
5) Downright incompetent testers. ("Oh, we don't need to test that.")

But, I would tend to disagree about your point concerning QA participation in code reviews of module level code. Frankly, module testing is the responsibility of development. The finest granularity that testing function should be concerned with is the interface level. (unless, of course, your org uses QA people to do module testing.) This is because testing is required to have an understanding of *more* components/modules than any given developer. To expect them to know the intricate workings of the interior of each module is unrealistic. To expect them to know the interface of those modules, how they behave together, the data flows, etc is quite reasonable. This reminds me actually of the biggest problem that I've encountered (addendum to above): poor or non-existent requirement documents. How the hell are developers supposed to do a reasonable job, and testers test it if there are no frickin' requirements?

Re:How the hell does this happen?

[Phil Wherry]

Hmmm. I'm just expecting Apple to issue a press release soon that says something to the effect of, "in retrospect, perhaps we shouldn't have subcontracted the installation script to RIAA after all."

Re:How the hell does this happen?

[whereiswaldo]

The sad part is, the users end up being the beta testers here. Companies can put out crappy products and let the end users find the problems. It saves a lot of money in QA. Plus, a lot of people seem to think this is acceptable.
Having used open source and commercial software, I'd have to say there's no clear distinction between which is more or less buggy. It comes down to companies or individuals. But, with open source, you CAN fix the bugs if you want, and you WILL get more frequent fixes. In the meantime, in either case, you're left sitting there with an unusable product until the fix comes in. Plenty of time to look for alternatives.

Re:How the hell does this happen?

[benedict]

I know plenty of people who program "for the thrill of writing code" and *still* can't code their way out of a paper bag.

It takes more than a love of computing to make a good programmer. In my humble opinion, it takes a fair amount of education. A brilliant but naive programmer can screw things up pretty impressively. I'd prefer to use code written by someone who isn't such hot shit but takes the time to learn APIs, read documentation, and familiarize himself with the idiom of the language and/or operating system in question.

New Apple Slogan

[Anonymous Coward]

Rip. Mix. Burn. Format. Reinstall.

Liability

[jeti]

I really wonder about the legal foundation of:
"You should've backuped. We're not responsible
for any damage that erasing all your data caused."

(Yes, it's in the license. But can it be valid?)

Re:Liability

[gig]

> you're generaly held responsible for
> the damage you do.

But in this case, the "you" is the user. The user downloaded and installed a software package that happened to have a bug in it, and in so doing, they may have lost data and have to restore from backups. End of story.

Software bugs are a Fact of Life. They weren't invented yesterday.

The ironic thing here is that the Mac OS X installer is rarely used ... iTunes 2 is maybe the third app I've ever had to run the installer for. Most apps just come in a disk image, and you mount the image and drag and drop the app where you want it to live. Or they come on a CD or DVD and you drag them to the hard drive in the same way. I prefer that over running the installer and letting it have free reign over the system.

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.)

Re:Liability

[wrt]

The EULA doesn't come up until after you install itunes. You accept the license agreement when you run it for the first time.

I didn't lose any data, that would have sucked.

Re:Liability

[Galvatron]

I sure HOPE it's valid, because it's a critical underpinning of the GPL. No one would write Free software if they could be held financially liable for any damage the bugs cause.

Re:Liability

[Sloppy]

If they're liable, then nobody can afford software anymore.

Re:Liability

[ichimunki]

I'm not certain, but I recall reading somewhere that if you get something for free, that certain warranty rights are not binding. Here is some support for that idea: http://www4.law.cornell.edu/uscode/15/2302.html. This posting is not legal advice, and is for entertainment purposes only.

Re:Liability

[geekoid]

This is a forum not to ask that question.
Many people will talk about whats "obvious" even though they have no legal reference.
EULA has never been tested to this degree, so the answer is really unknown.
Personally I'd like to see a class action suit against apple. I would like to get ever consumer advocacy group on the planet involved.
I think the public outcry may have a profound effect on EULA's.
Juyst because it's in a contract, doesn't make it binding.since the EULA is the worse kind of contract, vague, untested, overly broad, and doesn't apply to minor who may install software, it really need to be beat up in court.

Oh, come on...

[CrayBeast]

Don't they test these things, anymore?

Really, in the current economic climate, all the monkeys should have been thrown out of the high-tech jobs, leaving only clueful people.

How does a bug like this occur?

Re:Oh, come on...

[GISboy]

Really, in the current economic climate, all the monkeys should have been thrown out of the high-tech jobs, leaving only clueful people.

Well, what you said is the working theory, anyway.

Having worked in the corporate world and the academic world this is the furthest from the truth. The people with a clue, ethics, responsability, talent, skills or value customers are usually the first on the chopping block.
After all, the managers making those 5 and 6 figure salaries have to remain employed so they can continue the (vicous) cycle.

Cynical? Oh, yeah, been there, been IT, seen it happen too many times.

Could apple be any different? That is a tough one to answer. I would have to say no, but to a lesser extent, perhaps.

Why to a lesser extent? For the simple reason that Steve Jobs and Lee Iacocoa (sp?) understood two things about running a company/taking over one:
First get everybody on board with a plan to succede/improve morale.
Second (and this is the kickass part) when you clean house *never, ever* get rid of your workers.
Clean up/fire your middle and upper management levels.

This solves 2 problems (imagine a pyramid):
1) when most layoffs happen they happen to the "base of the pyramid". What happens when you weaken the "foundation" of a company/structure.
Yeah, it falls down or does irrepairable damage.
2)Wiping out the middle section brings those "at the top" closer to the base. Most executive understand the "how and what" of a business, but understanding the "who and why" is what keeps thing "moving forward".

If I remember correctly, Lee I was first, and Jobs subscribed to the idea...it may have come from a /. link when Jobs returned to Apple.

Very good interview.

Of course I've always said a "Phd/manager saying 'in theory' is akin to a used car salesman saying 'trust me' ".

I guess in my snide cynicism I found humor in your altruistic logic

Re:Oh, come on...

[Greyfox]

Clueful people cost more. We recently interviewed a few people for an open position and I reccomended the guy who could actually have helped fix our project up. Our team-lead went for the second most competant person we interviewed on the basis that the guy I wanted would be bored and leave quickly. Our manager went for the wet-behind the ears college graduate. The money involved was the largest factor.

Ask a bunch of hiring managers right now and I think they'll tell you that they'd prefer someone adequate for a job over someone perfect for a job if it meant a salary difference of $10K - $20K. This recession isn't going to lead to a concentration of clueful people in our industry. It's going to lead to a concentration of monkeys.

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...

Re:Good Read

[batobin]

Actually, your URL has a space too many. Here's one that works:

Link, or if you're scared I'm trying to show you porn:
http://newforums.macnn.com/cgi-bin/ultimatebb.cg i? ubb=get_topic&f=46&t=000865

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.

Re:Corrected version 2.01 already posted by Apple.

[Jeremy Erwin]

While timely bugfixes are to be expected, a certain level of competence should be expected from a software vender. This should have been caught before release.

The error in the installation script was, in part, due to Apple's relaxation of certain unix conventions regarding spaces in filenames--conventions that have proven useful. And while some might dismiss this as merely evidencing Apple's unfamiliarity with UNIX, shouldn't this have been caught by the Nextstep engineers?

Nonetheless, most x.0 releases are buggy.Windows 3.0 was widely regarded as half baked. OSX-10.0x was very slow. The subsequent x.1 release is usually far better.

This even extends into free software. linux-2.4.0 was buggy. gcc-3.0 was buggy. It used to be that there were no hard and fast deadlines for free software, but significant pressure to shorten long development cycles may cause corners to cut. The gcc team even has deadlines...

At least the standard installation scripts (provided by GNU tools) are reliable and trustworthy... (I hope).

Re:Corrected version 2.01 already posted by Apple.

[firewort]

Your friend shouldn't have been so quick to presume the bug would be found, even in a pre-release.

It would have been far better for him to have reported it, so that it would have gotten some attention-

Remember, the engineers would rather code it and forget it, but if a few users report the problem, they're forced to devote some time to seeing if it's repeatable, and fixing it.

Sure, Apple ought not to need suggestions and bug/issue reports from regular folks, but they give us that feedback page on their website--- Use it!

Re:Corrected version 2.01 already posted by Apple.

[firewort]

Apple's typical behavior in this situation (reporting bugs on an illegitimate copy of pre-release software) is _usually_ to quickly contact the bug reporter and get them to sign an NDA, and agree to be a beta-tester.

Your friend could have lucked into being a software tester for Apple, getting legitimately-obtained pre-release software.

Wide spread?

[panZ]

I'm guessing this has happened to a limited number of people. I used the old iTunes2 installer on a number of machines with multiple partitions as have my friends and none of us lost any data. What conditions cause this "feature" to occur?

Re:Wide spread?

[moof1138]

For this to come up you need to have multiple partitions, one of which is named 'Applications.' This is not too common, but it is done.
I knew a guy who did graphic design who did this, I always though it was kind of dumb back then, since apps not running on the boot volume in Mac OS 8.1 - 9.x took a performance/VM hit. It doesn't have that impact on X, but I still don't see much benefit.

[PATCH] Re:How the hell does this happen?

[Anonymous Coward]

There's a bug in you pseudo-code. Attached is a patch which fixes the problem.

--- itunes-install.pseudo-orig Sun Nov 4 01:36:11 2001
+++ itunes-install.pseudo Sun Nov 4 01:36:19 2001
@@ -1,5 +1,5 @@
if(installDrive->hasEnoughSpace()){
- return startInstall(instalDrive);
+ return startInstall(installDrive);
} else {
installDrive->formatRecklessly();
return startInstall(installDrive);

Re:[PATCH] Re:How the hell does this happen?

[jesser]

There's a bug in you pseudo-code. Attached is a patch which fixes the problem.

It's pseudocode. You can't patch pseudocode. You have to pseudopatch it, like this:

- return startInstall(instalDrive);
+ return startInstall(installDrive);

or like this:

Replace instalDrive with installDrive.

The bug

[hysterion]

Summarizing discussions on MacNN and the Apple Forum:

The problem appears to be in two portions of the installer script which could translate into rm -rf /your_drive, if certain paths $1 or $2 contain spaces:

#!/bin/sh

# if current iTunes pkg exists, delete it b/c of Installer bug
if [ -e $1Library/Receipts/iTunes.pkg ] ; then
rm -rf $1Library/Receipts/iTunes.pkg 2> /dev/null
fi

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

Though when I looked, nobody seemed to have found where exactly $1 and $2 are defined; also it might be that disaster only strikes with localized versions of the OS.

Re:The bug

[benedict]

Your post reminds me of a conversation I had with an Apple employee. He shared your opinion of the Unix tools. I challenged him to come up with a replacement syntax for the shell that wouldn't have any problems with spaces.

After I shot down his first half a dozen proposals, he started to gain an appreciation for the difficulty of the problem.

So how would *you* rewrite the shell to get rid of problems like this? Be specific. Remember, in 30 years of unix, no one has found a solution to this problem that doesn't break more things than it fixes. So if you do so, you'll be famous.

I wait with bated breath.

Re:The bug

[Phexro]

"...nobody seemed to have found where exactly $1 and $2 are defined..."

uh... $0 ... $n are the variables that store the command-line arguments to a shell script. awk scripts also wotk this way.

man bash, search for ARGUMENTS.

Re:The bug

[kijiki]

You can use newlines in a filename too. do you think that's a good idea?

Re:The bug

[benedict]

"Unix is passe" is passe.

Free Format

[starphish]

I've been looking for a good free format utlity with an attractive front end. Is there a PC port?

mmm...

[Wakko Warner]

...smell that? that's a steaming heap of Apple quality.

- A.P.

Need to have a warranty!

[burtonator]

OK.. so. Your hard drive has just been formated by Apple? You have lost months of work and potentially hundreds of thousands of dollars. What will you do now?

Are you going to sue? Did you read your EULA (End User License Agreement)? You probably waved that right when you said "OK".

Apple probably waived all warranty when you installed the software (in some states this isn't legal though)

This is one area where the law needs to be fixed.

With Open Source software at least you have the ability to read the source code.

Imagine if Ford were to wave any warranty with your next Explorer.

Kevin

Re:Need to have a warranty!

[Macka]

Hmm .. I'm not going to waste a moderator point jacking this back up again, but this is NOT a Troll. The man has a point! This IS an Apple article, and MacOS X is supposed to be a click and point friendly face to Unix where you don't have to be a command line jockey to get things done.

Also, the 'read the code and fix it yourself' argument is starting to wear very thin, as both Linux and MacOS X can quite easily be found in the hands of non-techies these days.

To whoever mod'd this down as a troll .. shame on you, for not being more open minded!

Re:Need to have a warranty!

[Detritus]

You have an obligation to take reasonable precautions to protect the data on your computer. That means making backups of any valuable data. Are you going to sue Western Digital if your hard drive fails? What if it gets fried by a lightning strike? Even if Apple was found to be grossly negligent, they shouldn't be held responsible for data that was lost due to the negligence of the computer's owner.

Re:Need to have a warranty!

[frleong]

Yeah, it is also a negligence of the computer's owner to have installed Windows 95 or MacOS 9 infested with nasty bugs. MS and Apple shouldn't be held responsible for data that was lost. Am I following correctly your logic?

Re:Need to have a warranty!

[stripes]

With Open Source software at least you have the ability to read the source code.

In this case the bug was in the installer, which is a shell script and quite readable. It was a novice shell script error, which is understandable since Apple is a novice Unix OEM...

Anyway, you can read that part, and even fix it.

Still sucks though.

Re:Need to have a warranty!

[egomaniac]

I love open source as much as the next guy, but I'm getting sick and tired of the "open source fixes all ills" crap.

Are you going to sue? Did you read your EULA (End User License Agreement)? You probably waved that right when you said "OK".

Oh, and you would have legal recourse if this had been open source software? Whom, pray tell, would you sue then? You generally can't sue the responsible party if it's closed source, and you generally can't sue the responsible party if it's open source, and from this you conclude that open source is better is this respect?

With Open Source software at least you have the ability to read the source code.

And, in case you haven't noticed, a dozen people have posted the offending code from this particular problem as well. It was a shell script, so the code was in plain sight. It was also fixed pretty damned quickly, too.

Imagine if Ford were to wave any warranty with your next Explorer.

Or better yet, imagine if your next Explorer were hacked together by hundreds of college-age geeks who had never once met one another, and if you had problems with it the response was "Well, just open up the hood and fix it. You can see how it all works".

I generally use open source in preference to closed source, but I'm getting sick of the attitude that closed source = bad and open source = good. I've used some great closed source products and some truly crappy open source products in my time.

Re:Need to have a warranty!

[geekoid]

Yes I would sue my HD company if it failed in an unreasonable time.
Having seen a company do this successfully, I now it can be done.

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.

Re:Nature of the bug

[Florian Weimer]

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.

But even experienced UNIX users have problems to cope with the fact that on a traditional UNIX file system, file names can include all characters except '/' and NUL. For example,

find /some/path -name \*~ | xargs rm

might delete much more than you want, and it's especially dangerous to do this if you are the root user and process directories where unprivileged users have write access. (Yes, I know, the -print0 and -0 options for find and xargs exists, at least in the GNU versions.)

Anyway, it's quite embarrassing to make such a mistake in an installer. It shows how little testing software gets nowadays before it is released. I can't imagine that this couldn't have been noticed by testing the installer on several internal machines (and not just developer ones).

Re:Nature of the bug

[ceswiedler]

I believe that filenames can even include /. Shells might not like it, but Unix filesystems don't care.

Re:Nature of the bug

[scrytch]

I believe that filenames can even include /. Shells might not like it, but Unix filesystems don't care

Shells don't care about /, the filesystem most certainly does. Path parsing is not done by the shell, it's done by the filesystem. creat() and open() and company will all fail if you try to have a file with a slash in it. Try it with a C program sometime.

Re:Nature of the bug

[crucini]

Yup. Shell is a beautiful, elegant, but treacherous language. The combination of variable expansion, globbing (*'s and ?'s) and backticks allow one line of code to have nearly infinite meanings. The error in this script is probably present in many scripts on production Unix systems. Sysadmins don't usually expect spaces in file names. Also, adding quotes doesn't protect against the variable containing a '*'. And I'm sure there are other gotchas.

If you want to learn shell, I suggest lurking in comp.unix.shell.

Re:Nature of the bug

[benedict]

Path parsing is not done by the filesystem.
It's above that layer.

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

[Skapare]

It also shows one of the weaknesses of a programming language which is based on collections of things (in this case token words on a command) or data structures which can be changed merely by the value of some part of it (e.g. a variable with spaces).

Re:quote

[Gid1]

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

When I went to download it (before the bugfix) , I did notice that the download page prominently said something to the effect of "If you have a previous version of iTunes installed, you must remove it first". Fortunately, for once, I followed those instructions.

In retrospect, this is a little odd if the installer had the ability to remove the old version. Hrm.

<paranoid>
Maybe this is one of those times when the programmer noticed the bug just before release and the manager cared more about the release deadline than the bug and said "Well, release it for now, and start working on the x.y.1 release." In my experience, not the first time that's happened!
</paranoid>

Hrm.. just noticed another thing. 'if [ -e $2Applications/iTunes.app ];': even if iTunes *had* been de-installed... if '$2' had whitespace in it, -e would still fail, giving an [: xxx/Applications: unexpected operator error (if 'xxx' was the part of the volume name after the whitespace...

Depending on what this script is run on, it might only have effect on people who choose to install it on partitions with whitespace -- so, if your chosen partition didn't have whitespace but your other partitions did, it might not affect it. *shrug*

Massive cock-up on Apple's part, all the same.

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.

page out of Roxio's book

[Alcimedes]

you know, the funny part was i was cursing a blue streak when installing roxio cd creator 5 toasted my win2k machine. what are the freakin' odds, i would rant? why the frick is a cd software package set up to kill my machine?

well, i guess it's catching, whatever it is.

lol, i think i'll be waiting a few weeks after the release of software from now on. bleeding edge one to many times.

This might be very good.

[Krapangor]

I usually don't have very much space on my harddisk because it very small and i often can't decide which pictures to delete i downloaded from the internet.
So this installer comes in very handy because it deletes just all data and you don't have to decide whether to delete the picture of all these nice kitties or not.
So you have much more space on your harddisk and can download again much more nice pictures from the internet with cats.
My problem is however that i don't have an MAC and i hope they port it to linux soon so that i have again nice 30 megabytes of free harddisk space.
It is of course very sad that people with important data have lost all important data but you can't have much space and important data on your harddisk all the same time anyway.

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.

Re:The big mistake here...

[aberkvam]

It sounds like you aren't familiar with what iTunes does. iTunes isn't just a pretty version of WinAmp. It actually is a CD ripper and CD burner that handles audio and data CDs. It supports the CD-RWs that come with Macs as well as many third party CD-RWs In order to properly support CD burning it has to install drivers "outside its bundle". It has to change things outside of iTunes.app.

I will admit that most applications should just use the "drag and drop" installation and Apple agrees. But there are some cases where the use of an installer can not be avoided and this is one of those cases.

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:OS 9 Forever!

[motherhead]

you're just a touch insane. I too have been buying macintoshes since system 6 (by the way, i would love to hear your systems 2 through 5 user experiences...) .

yes, while system 9 is just so terrifically mature that it stuns you with it's depth. i also remember how much I thought that system 7 was an anathma to the Macintosh look a and feel and "useability".

I detested OSX and need my mac to make money with, so have I little time for flakey eye candy. But ever since I Installed OS 10.1 on my drive i have yet to boot into OS 9. Yes it is far less mature and has some goofy little idiosynchosies but it also runs all my DTP/WebDev OS 9 apps perfectly, but then i can also exploit 10's native apps to get grunt work (word proc, mp3 playing, browseing and proofing etc...) all multi-threaded and so on... every day i am amused to find a hidden little nuance to aqua, and i also get to run xdarwin interleaved with aqua so i can run BSD, classic and OSX apps flawlessly, simultainiously.

Also this: Quartz.... mmmm... beatiful display postcript (PDF, i know) love...

So i sympathize with you. and perhaps some lunitic will come up with a nice OS 9.2.1 theme and theme manager to run it over aqua for you. but I think apple is kicking big OS ass with 10.

OS 9 forever? my ass, how many times did you reboot today?

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:bogus shell quoting rules

[fwr]

There are situations where retokenizing is a desired behavior. I'd rather classify it as inexperience by the programmers who wrote the script with the scripting language. Anyone who has experience with shells knows that this is the way they behave and program accordingly. Blaming the programming language instead of the programmer is like blaming the end-user instead of Apple...

Re:bogus shell quoting rules

[dvdeug]

Very few cases exists where retokenizing is useful, compared to the cases where you have to quote and doublequote and use -print0 and whatever else. It could have been provided by a function instead of as a default behavior.

I don't see why we should blame the programming language. The fact that

#!/bin/sh
rm $1

doesn't work is nonintuitive and painful. If a programming language has a 'feature' that results in a lot of bugs then that feature should have been designed a different way, especially in a language like shell where bugs like these can be so dangerous.

Blaming the programming language is like blaming Apple; the programmer should have double checked his code, but trusted the language not to annihilate everything on a simple typo; the end-user should have double checked the code, but trusted Apple not to annihilate everything on a simple uninstall.

Re:bogus shell quoting rules

[mj6798]

Ah, I see, you live by the "tough man" approach to programming. The fact is, people keep shooting themselves in the foot with this. It's unexpected because it's different from almost any other scripting language. And it's easy to get the same functionality with a different notation. That's why it's a design flaw and that's why the Bell Labs successor to the Bourne shell fixed it.

Re:bogus shell quoting rules

[mj6798]

Oh, I agree: Apple is fully responsible for this, and programmers should get this right if they use the Bourne shell.

But if a system is designed in such a way that people frequently make a certain mistake, and if it is easy to change the system, without limiting its functionality, to keep people from making that mistake, then the system has a design flaw. This applies to the Bourne shell, and that's presumably why its successor at Bell Labs doesn't behave this way anymore.

As for Apple, they should have been using decent package management. If they do need to script, they should have been using a scripting language that gets this right (Perl, Python, etc.). As a last resort, they should at least know their tools.

Re:bogus shell quoting rules

[dangermouse]

Ah, I see, you live by the "tough man" approach to programming. The fact is, people keep shooting themselves in the foot with this. It's unexpected because it's different from almost any other scripting language. And it's easy to get the same functionality with a different notation. That's why it's a design flaw and that's why the Bell Labs successor to the Bourne shell fixed it.

No, I live by the "hammer for a nail, screwdriver for a screw" approach to programming. It's not unexpected behavior if you don't look at an apple and say "hey, that's just like that orange I've been eating."

Bourne is not, nor is any other derivative shell, very much like any other scripting language that was not based largely upon it. You have only to look at the structure of the [ operator, the way control structures are broken up, and the way variables are expanded to recognize that. It's designed primarily for use on a commandline... the fact that you can write your scripts to a file and run them through the shell non-interactively is bonus.

That said, Bourne is usually the right tool for software installation scripts on a Unix machine. You just have to recognize that you're not wielding a screwdriver.

Also, I do realize it's a common mistake. But so is dropping a semicolon or forgetting to close parens in your C-like language of choice. That doesn't make the need for a semicolon or a close-paren a design flaw.

Re:bogus shell quoting rules

[dangermouse]

The fact that


#!/bin/sh
rm $1


doesn't work is nonintuitive and painful.

Erf. It does work, and it is intuitive, if you stop thinking of Bourne as a scripting language that can be used interactively and start thinking of it as a shell that can be scripted.

If I call that script like so:

script something else again

I would expect it to remove 'something', which it does, and leave 'else' and 'again' alone, which it does. If I want it to remove all three, I have to do:

script "something else again"

It will then tokenize the string "something else again" and pass it as a set of three parameters to 'rm'. This is a good thing. It allows me to deal with parameter grouping and pass-through efficiently and intuitively. And since this is a shell, that's very helpful. It is truly scripting and not programming. You're feeding the shell a list of commands to run. It just happens to have a few handy programming features like flow control and conditionals.

If you're in a position where you don't just essentially need a bunch of external commands to run in a given sequence, then for God's sake use a programming language like Perl, Python, Tcl, or even Ksh (which is as much a programming language whose interpreter serves as an interactive shell as Bourne is vice versa).

Re:bogus shell quoting rules

[jesser]

It's very hard to cause data loss with a missing semicolon. In all likelihood, you'll get a syntax error when you try to compile.

Re:bogus shell quoting rules

[jesser]

If variables are supposed to be lists, then why isn't $1foo (without quotes) a syntax error?

Re:bogus shell quoting rules

[dangermouse]

Because bash recognizes $1, substitutes it, and concatenates it with 'foo'. How hard is this?

Re:bogus shell quoting rules

[jesser]

Because bash recognizes $1, substitutes it, and concatenates it with 'foo'.

That's not a justification any more than "Windows crashes because it dereferences dangling pointers" is a justification for Windows crashing.

If variables really are lists (like you said), then $1foo means "concetenate foo to the last term in the list". How often do you want to do that? I'd bet that $1foo is more often typed by someone who didn't realize $1 could contain a space than by someone who actually wants to treat $1 as a list and concatenate foo to the last term. We just saw an example where $1foo not being a syntax error led to severe data loss. Can you give a reason why bash shouldn't issue an error or warning when it sees $1foo outside of quotes?

Re:bogus shell quoting rules

[dangermouse]

If variables really are lists (like you said), then $1foo means "concetenate foo to the last term in the list". How often do you want to do that? I'd bet that $1foo is more often typed by someone who didn't realize $1 could contain a space than by someone who actually wants to treat $1 as a list and concatenate foo to the last term. We just saw an example where $1foo not being a syntax error led to severe data loss. Can you give a reason why bash shouldn't issue an error or warning when it sees $1foo outside of quotes?

No, $1foo means "expand $1 and append foo". You, the intrepid Bourne scripter, should realize that $1 may very well contain IFS characters, recognize what that will mean if the string is retokenized, and quote appropriately.

Look at this:

VARIABLE="$VARIABLE $ELEMENT"

This is a common way of building lists in Bourne. The reason this is common is that it is understood that $VARIABLE will be tokenized when it is expanded, and word splitting on IFS characters will occur. It is also commonly understood that if you do not want a string to be word-split, you quote it so that its IFS characters are ignored. Like I said before, not hard.

I'm sorry, but it takes all of ten seconds to grasp the fact that variables will be expanded and their words split. Occasionally you take it for granted that a list will only have one element, and get away with stuff like $1foo. However, it's not something you do unless you have total control over the contents of $1 (as in, say, a function you've defined that only you will call), and even then it's bad practice.

That's not a justification any more than "Windows crashes because it dereferences dangling pointers" is a justification for Windows crashing.

I couldn't have said it better. The problem there is that someone unfamiliar with basics of pointer manipulation went and dereferenced a null one... the problem is not that the language let him have a null pointer to begin with.

Re:bogus shell quoting rules

[spitzak]

I think the suggestion is that '$1foo' should produce an error if $1 contains a space. But '$1 foo' (notice the space after $1) does not produce an error. Also no error is produced if any of this is inside quotes.

I would agree that it seems unlikely that somebody will want to append a word to the last item in a list, and that any occurence of this is an error. If somebody did want the real effect of $1foo they would have to put it in quotes and into a temporary variable, and then insert that temporary variable.

Re:Stupid, stupid, stupid

[Lars T.]

How many of those hundreds of NDAd beta testers had a drive with a name that either started with a Space or ended with one (but not in the middle of the name). None. Yup, the error was stupid (like most shell script bugs), but not really easy to find.

Re:OS 9 Forever!

[darkov]

Granted, System 10 is more stable becuase of memory protection and has better task scheduling, but my 9.2.1 is heaps stable (as long as I don't run MS apps, generally). But I use Macs becuase they're a pleasure to use, and all the little things count. Quartz is loverly and I wish that GX lived on, but they don't improve my work. Pissing around trying to work out how the hell to get 10 to connect to my AFP server and other simple things which seem impossible wastes my time. 10 may have it's own nuances, but they're nothing like 9. What exactly is the big win changing all the subtlities of the UI in an arbitary fashion? Believe it or not, stability and memory protection are incremental improvements for your average user, delivered at great expense of it's usability.

On the subject of the earlier systems - they were fantastic. Why wouldn't they be when the only alternatives were DOS and a very broken early Windows.

Gotta be said

[Lord_Pall]

So i guess the Ipod/Itunes combo really IS a killer app.

Relative severity vs. a MS flaw

[jht]

Apple posted the initial update either late Friday or early Saturday (I'm not sure exactly when). It was pulled by late in the morning Saturday, they posted a warning shortly afterwards, and when I got up this morning there was a fixed installer online to use.

The Classic version (which most Mac owners are still running) was fine, and the bug seems to have only hit people who didn't follow Apple's instructions that said "remove the old one first" and/or had multi-partitioned drives (multiple partitions aren't nearly as common among Mac users as they are among Windows and Linux users).

So Apple made a gross mistake on one hand, but on the other hand they owned up to it quickly, pulled the offending installer, and fixed/reposted it less than 24 hours later. Most Linux vendors respond about as well, Microsoft usually doesn't (though they were very good about pulling, fixing, and notification with their recent RDP fix that knocked people's Terminal Server systems off the network entirely).

The other mitigating factor was that there aren't that many Mac users relative to the installed base who were affected by the bug - but unfortunately the people who were likeliest to be affected (users who are already running 10.1 as their base OS, have multiple partitions, and don't read the instructions thorougly because - after all - "it's a Mac, who needs instructions?") are exactly the kind of Mac "power users" who swarm Apple's servers constantly looking for new stuff and install it the second it's posted.

I run 10.1 on my TiBook 667, and I downloaded the update. But I deleted the old iTunes version beforehand and only have a single 30GB partition, hence the install went fine..

Re:Relative severity vs. a MS flaw

[nycdewd]

Tell it, bro. You have got it down, especially: "the people who were likeliest to be affected (users who are already running 10.1 as their base OS, have multiple partitions, and don't read the instructions thorougly because - after all - "it's a Mac, who needs instructions?") are exactly the kind of Mac "power users" who swarm Apple's servers constantly looking for new stuff and install it the second it's posted." Damn straight! And, fortunately for me, the only difference between said "power users" and myself is that I CAN READ and I DO READ. So, as instructed by the iTunes2 ReadMe , I deleted the previous version of iTunes2 (beta, got it from a Hotline server in Japan) from my OS X partition of my HD which has THREE partitions, BEFORE I installed the official release of iTunes2. Go figure, my partitions are intact. No loss of data. iTunes2 is freakin' great.

Re:Relative severity vs. a MS flaw

[sheldon]

Yeah!

If I recall correctly when SP6 was noticed to affect Lotus Notes it took Microsoft 26 hours to respond!

Those bastards!!!!!!!!

Re:Relative severity vs. a MS flaw

[jht]

To all the folks who thought I was praising Apple (or blaming Microsoft) - I wasn't! Apple was a bunch of dummies for letting that code escape the dungeons in Cupertino! Really!

Now that I've vented a tad, I'll re-iterate. It was a stupid bug that could have easily been avoided. But OTOH, Apple does not really have a track record of releasing software this broken (or at least, installers this broken), so their response was very good - at least as good as what we've come to see from other vendors if not better than most. That does not, mind you, excuse the severity of the bug - rather, it praises the response.

And if you had followed the CLEAR INSTRUCTIONS to delete the old iTunes first, you never would have encountered the bug in the first place, no matter how many partitions you had. Many (perhaps most) Apple users, unfortunately, do not bother reading instructions.

Every company makes stupid mistakes. The tough part is to handle it well when bad things happen, and Apple did OK (not perfect, because people lost data, but they took appropriate steps quickly) in that regard.

Re:Relative severity vs. a MS flaw

[Erasmus Darwin]

"And if you had followed the CLEAR INSTRUCTIONS to delete the old iTunes first, you never would have encountered the bug in the first place,"

Still, there are certain reasonable expectations and assumptions that people make when it comes to reading the directions. For example, while there are generally instructions on, say, a box of toothpicks, it would be unreasonable for a manufacturer to produce toothpicks that explode if you use them improperly. As long as I don't try and stab myself with it, I expect the tootpick user-error problems to be limited to failing to remove food and the occasional splinter.

With a car or a handgun, on the other hand, it's not unreasonable for a user to read the manual cover to cover (possibly multiple times), reference it again as necessary, even obtain additional instruction and certification for using the device. These are things that're inherently dangerous if misused.

With application-level software, reasonable expectations of the problems of a failed install include:

• The new version doesn't work
• Both versions are installed but unusable
• The user-created data associated with the old version gets wiped out by the installer (generally the worst case scenario and borderline unreasonable)

Personally, I generally backup the data from the previous install to another directory (if it's something I can't live without), then go ahead with the install. At worst, I expect that I'll have to uninstall both versions, maybe manually clean up a few files, and then start over. A few extra minutes of work in exchange for a few minutes of laziness. In the long run, I've found that I win.

Now, if the software were something other than just a standard application, I'd take more care. You can bet that I'd be a lot more paranoid when using software that's supposed to fiddle with partitions, as that's something you'd reasonably expect to be able to destroy your harddrive. But reading for the directions for absolutely everything would just be insane. I don't have that much free time.

Re:OS 9 Forever!

[StorminNorman]

I'm going to give you the benefit of the doubt and assume you're not trolling.

Mac OS X is based on UNIX, a design which, if you'd noticed a previous story today on slashdot, is now 30 years old, much older than Classic Mac OS.

Mac OS X has a carefully redesigned UI that actually works really well. Believe me, I haven't used Classic Mac OS in about 4 weeks now, and even then it was for DVD playback due to an oversight in Mac OS X. The new UI is just as carefully designed, and just as carefully planned as the old one. It has one disadvantage however:

It's new.

That means that there are going to be kinks for a while yet (ever used Mac OS 1.0? I have, and believe me, it has more UI kinks that Aqua does now).

That said, I can't go back to Classic Mac OS for two reasons: Protected Memory and real Multitasking. Between the time that my Centris died, and the acquisition of my iBook Dual USB, my primary computer was an Intel system running Debian Linux. I can happily say that I was able to put up with KDE's quirks (it's nice, but it's got a long way to go before it gets close to Mac OS for usability), simply because the system NEVER BLOODY CRASHED!. Seriously. The only reboots I perform on it are for power outages and kernel upgrades.

Mac OS X is just the same. While I got a few kernel panics on the older 10.0.x series (3... all of them while in public for some reason :( ) I am yet to see one in Mac OS 10.1.

The point is, I would happily live at a commandline if it meant the OS wasn't going to freeze up at least once a day, or if I could happily run as many applications as I wanted without worrying about memory (No more memory size settings! YESSSSS!). And that's not even mentioning the fact that the system actually MULTITASKS. Whoa! Who'd have thought that a Mac would ever be able to multitask and provide memory protection? They've only had an MMU for what? 10 years now?

I love Macs, always have, always will, but the old OS was kludge upon kludge upon kludge. It's old, It's broken, it's been replaced. Stop using it, please. And Aqua takes all of 5 minutes to adjust to from Platinum. It's harder to jump to windows from Platinum than to Aqua.

I mean seriously... would you go on using Windows on an Intel system if you knew that a newer and better operating system was available that didn't have all of Windows bugs?

Why I hate the software industry

[Carnage4Life]

You have an obligation to take reasonable precautions to protect the data on your computer. That means making backups of any valuable data. Are you going to sue Western Digital if your hard drive fails?

People regularly sue if hardware is made faultily. Toshiba paid billions to settle a lawsuit with floppy disks that never showed up in the field and couldn't be reproduced. I personally have lost track of the number of class action lawsuits I've seen for faulty computer products.

What if it gets fried by a lightning strike?

Being struck by lightening is an act of nature which is completely different from human negligence. Please get your analogies right.

Even if Apple was found to be grossly negligent, they shouldn't be held responsible for data that was lost due to the negligence of the computer's owner.

Why shouldn't they be held responsible? If attaching your DVD player to your TV blows it up or your fax machine shreds your documents, are you also liable in such situations? Quite frankly I am disgusted with the attitudes of most people in the software industry that assumes that shoddy work is inevitable (all software has bugs? WTF?) and then blames customers when their shittily written software fails to behave as it should.

Programming is less difficult than building a bridge or an airplane and yet software companies have hoodwinked the public into making it seem that badly made software is a fact of life. One day people are going to realize that the software industry has been shamming them all this time and the lawsuits will start to pour in. This is probably when software companies will finally go back to using techniques developed decades ago to improve and measure software quality but by then the damage will be done.

Re:Why I hate the software industry

[Some Dumbass...]

Quite frankly I am disgusted with the attitudes of most people in the software industry that assumes that shoddy work is inevitable (all software has bugs? WTF?)

Not a programmer, obviously.

You need to understand that not all bugs are actual errors or "shoddy work". Sometimes it's the interaction between multiple pieces of code, each of which works perfectly well, which causes the problem. Sometimes it's people using the code in unexpected ways which causes the problem (the programmer is not omnipotent, remember). That's why programmers say "all software has bugs". It's not that all software has flaws, but rather that it's almost a sure thing that any given piece of software can be used in a way which causes a problem (or "bug") to arise.

Take this iTunes software bug, for example. Even here, it sounds like there would have been no problem if people followed the directions. Given the simplicity of the fix, it should probably still be called a programming bug. However, what happens if some user actually had the old sh shell on there instead of a link to bash? There could be some subtle errors, as bash does not behave 100% like sh. Bug? Probably not, unless you argue that the programmer should have seen it coming. All right then, suppose some user decides that they only want to use csh, so they link sh to csh instead of bash (note: a Bad Idea)? The installer wouldn't work at all. Bug? Hardly.

The point being, the programmer can't plan for every contingency, and this can lead to problems which people call "bugs". That's why "all software has bugs"... because even if the code is flawless, there's no guarantee that it won't fail somehow.

Re:Why I hate the software industry

[geekoid]

Software failure can be just as catostrophic as a brige/building failure.
What id the software the engineer usues is faulty, and the bridge collpases?
what if vital signs our misreported to a doctor?
etc, etc, etc ...
Speaking of engineers, here come custodial engineering now.

Re:Sue them.

[gig]

> Its a virus - it hides behind a legitimate
> program, performs some sort of check, then
> delivers a payload. If thats not a virus,
> then i don't know what is. Just because
> Apple may 'claim' its a mistake, is no
> excuse. People have gone to prison for
> less so i say, give them a big fat law
> suit.

Are you listening to yourself?

Re:it's not that far-fetched.

[gig]

iTunes is part of Mac OS X. If Apple had an application/OS split, then the iTunes folks would be in the OS camp. It comes with Mac OS X, and parts of it are in the system itself (CD burning stuff) and need to be updated by an installer. That's what the installer is for. Most apps do come on disc or disc image, so the installer is very rarely used.

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.

Renumeration Remuneration

[eyewell]

Renumeration has been addressed. It is aparently no longer 2.0, but 2.0.1.

However, this does not address any Remuneration!

not mine

[IRNI]

my drive is partitioned. the installer went fine. my drive isn't messed up. nothing missing. must suck for whoever it did happen to who doesn't have a backup.

Worked for me.

[prwood]

I have a Pismo PowerBook with MacOS X 10.1, and I downloaded iTunes 2 immediately after it was released. My hard drive has two partitions, one for MacOS 9.2.1, and one for MacOS X 10.1. I also already had a previously installed copy of iTunes on both drives. I ran the iTunes installer, and everything worked fine. It didn't wipe out any data, and I am quite enjoying the new iTunes 2. I

Gee, I guess I was just lucky?

Aplle lies

[frost22]

This problem only came to light today, and they have a fix out the same day.

No. Apple lies:
- they have not even admitted failure. Instead they engage in Microsoftian doublespeak talking about an "issue". Instead, they should write: "due to a defect in our software installer ... "
- they don't take responsibility. No compensation for people who sufferered sever data losses.

Posting a patch isn't always enough.

You just don't wipe people's hard drives. Never. Having an installer that is even capable of such is a sign of faulty design. They are to blame.

f.

Re:Aplle lies

[stripes]

Having an installer that is even capable of such is a sign of faulty design.

How do you make an installer that can remove the old version of a program, and yet have zero chance that it never removes the wrong thing?

(yes, it was a bad bug, very bad, but I'm not sure how you design a drool proof installer that has zero chance of deleting the wrong thing -- I know how to do a not drool proof one though. Put iTunes2 on a disk image along with a README that says "delete the old one before installing the new one").

Re:Aplle lies

[haruharaharu]

ow do you make an installer that can remove the old version of a program, and yet have zero chance that it never removes the wrong thing

Easy. require apps to declare their contents to the system and provide an interface to manage these apps and their versions. Then require that apps use that interface exclusively to manage them.

It's really hard to wipe an entire drive with uninstallComponent("iTunes", VERSION_ALL);

Re:Aplle lies

[stripes]

Easy. require apps to declare their contents to the system and provide an interface to manage these apps and their versions. Then require that apps use that interface exclusively to manage them.

Already does, you put them in a direcory named Foo.app where Foo is the name of the application, then users can move it around without things getting out of sync...

It's really hard to wipe an entire drive with uninstallComponent("iTunes", VERSION_ALL);

That depends on how "uninstallComponent" is implmented. If it is written in a shell like language it can be pretty easy...

Wrong, mind you, but not so hard to do wrong. I would guess some Linux and other generic Unix installers have problems with spaces in file names... I know for sure they have problems with display numbers other then zero, and this mistake is about as basic.

Re:Aplle lies

[jcr]

How do you make an installer that can remove the old version of a program, and yet have zero chance that it never removes the wrong thing?

The obvious way is to rsync the existing app's directory with the new version, instead of delete-and-replace.

-jcr

Re:Aplle lies

[stripes]

The obvious way is to rsync the existing app's directory with the new version, instead of delete-and-replace.

That still deletes files, merely saying "resync" does not magically fix that. I liked the "move the old one to the Trash" suggestion better.

Re:Aplle lies

[jcr]

Check the man page on rsync. When you rsync a directory with another directory, you're not running a risk of deleting anything outside that directory. (Like, say, /*)

-jcr

Re:Aplle lies

[stripes]

Check the man page on rsync. When you rsync a directory with another directory, you're not running a risk of deleting anything outside that directory.

Yes, but rsync uses unlink (or it did in 1995, which is the last time I looked at it's source). It might manage to destroy everything, like if you accidentally specify the target wrong (great...my whole disk has been replaced with a single copy of iTunes and nothing else).

I'm not saying nothing is better then what Apple uses (an installer that runs a shell script), but that nothing that aims to do the same thing will have zero chance of deleting the wrong thing. In passing I'll also mention that it isn't obviously worse then many other Unix installers (you know, the ones that just run random shell scripts!), but Apple has the misfortune of having a user base that tends to use spaces (and punctuation) in their file names...

Re:Aplle lies

[stripes]

Well, you give it the "list of files" of the old installations, and make it delete all files from those old installations that do not contain any user-data. (e.g. leave out the "initial database" that is distributed with the program).

That still doesn't have zero chance. Your linked list might be damaged by another part of the program, either overwriting the link part, or a name part. You can complain that that would be due to a bug, but so is the shell script problem.

Zero is a hard goal to reach. Impossable even given the chance of DRAM errors.

You can get a little closer if you try this:
for (tp = file_list; cnt = N; tp;tp=tp->next) { assert(cnt--); unlink(tp->fname); }

Of corse we both left off finding the package install location (i.e. translating Foo.app/MacOS/Foo into "/Volume/Name of Volume/Applications/Foo.app/MacOS/Foo"), which is where the script went wrong, so we have a few more chances for error...

There is also a problems with the resource fork, in OSX it has been replaced. Resource Bar in program Foo is stored as Foo.app/Resources/Bar, so knowing all the files that Foo has requires knowing all the resources it creates, which may be hard to know ahead of time.

It also can be a problem because one may not know all the files in the iTunes package, it is clearly known for past versions, but not future versions.

I won't mention dumb-ass users replacing iTunes files with their own :-)

See the missing check if the unlink works? That's intentional. We're not interested if the remove of the file worked. If for example the user decided to write-protect some of the files (actually directories) we don't want them deleted.

I see it, it might be a bad idea if the file is a kext, or some random incompatable shared lib or kernel module. It is still a valid design choice though. It would be better if you told the user which files you wanted to delete but didn't because the user had protected them.

I still like to solution of moving the things to the trash. It also doesn't have zero chance of not deleting things, but it probbably won't. It definitly doesn't have no chance of moving the wrong stuff to the trash, but if it does it is not so hard to move them out, definitly simpler then undoing an rm.

Why using scripting anyway?

[SCHecklerX]

If you'd use a scripting language that allows system-independent calls, shit like this would be avoided. Instead of shelling out to another command (rm in this case) You would call "unlink" with the PROPER parameters in the first place!

Oh well.

So old, it's a classic joke

[McD]

From the classic old joke list "How To Shoot Yourself In The Foot" in various programming languages and computing environments, here's the entry for Unix:

% ls
foot.c foot.h foot.o toe.c toe.o
% rm * .o
rm: .o: No such file or directory
% ls
%

Same bug. Welcome to the world, Apple. :-)

Peace,
-McD

Bias and stories?

[SilentChris]

I know we usually have the anti-MS, pro-everything else bias around here, but I was wondering: does anyone have any stories of Microsoft software doing anything similar? I know the Linux installs are pretty adament during the partitioning process ("Watch out! Look out!"), but I can't think of anything by MS doing the same thing.

Can Mac really be the anti-Christ? :)

100BG! Ouch

[dbretton]

I personally lost more than 100GB of data.
....
....
Somewhere, in a little corner of the basement of a house, someone is installing their new iTunes...

{blip, squeek}.. Oh man, this is sooo cool!
{HD Grrrrinnd!!}
huh? What thee.. !!

NooooOOooooOOOOO!!!! My PORN!!!
Oh my God!

Later that day, at a Starbucks, we see a man, trembling as he sips is triple MochaBucka Latte-chino...

Brtney... GONE!
Pam....GONE!
Margolis....GONE!
That chick doing the horse...GONE!

My life is over....

Re:Ahh... Imagine if this were a Microsoft product

[phillymjs]

Yet here in these responses I see the simple realization that some idiot made a mistake writing the installation script. Are you sure?

Yes, because on the Mac, the presence of multiple partitions != dual-booting user. OS X will reside quite happily on the same partition as OS 9.x, and you can choose between them with the Startup Disk control panel.

The only advantage I found to putting OS X on a different partition is, you can select which operating system you want to boot in every time you power on the machine, by holding down the Option key until presented with the menu.

~Philly

Exactly.

[mindstrm]

This is not to say that you can't negate yourself of responsibilty... but that would usually require some kind of negotiation, and contracts signed and notarized by lawyers or something.

ie: Where it can be very clearly demonstrated that both parties thoroughly understood, in detail, the terms of the contract.

Just curious.

[mindstrm]

But what kind of drive/storage device did you have that had 100GB on a partition?

The shell script not the problem...

[A_Non_Moose]

You have to realize that iTunes has an equalizer now.

After the installer formats your HD, you can record the high pitched scream you emit into an mp3 and then change the pitch to all bass.

So, now Apple just "equalized" itself with all other unicies.

To Apple I say, "I feel your pain" but you need to "strategize" some more.

Ow, crossing OS, platform and political lines... for shame! for shame!

(on a side note, modding me down as overrated because of my +2 bonus makes about as much sense as hating people for being intelligent...Oh, wait, that is what happens to "us" nerds all the time... I just answered my own question, never mind...so, being different is ok, as long as you are different like everyone else? Heh, makes sense...NOT!)

Yes I'm an esoteric, tenacious, longwinded SOB.

I'll never need therapy as long as I can post to slashdot.

Orbb: "keep talking, I'm reloading"

Re:The shell script not the problem...

[Rendus]

(on a side note, modding me down as overrated because of my +2 bonus makes about as much sense as hating people for being intelligent...Oh, wait, that is what happens to "us" nerds all the time... I just answered my own question, never mind...so, being different is ok, as long as you are different like everyone else? Heh, makes sense...NOT!)

You forget the purpose of the +1 bonus. It's not to be left on all the time, but only used on comments that deserve a +1 off the bat. At the very least, this post doesn't qualify. Therefore, the comment IS overrated, and deserving of a -1 moderation because of it.

The +1 bonus is NOT a "Hey, I'm better than everyone!". It's a slight bonus to being a well-behaved member of Slashdot, which are few and far between. There's an expectation that you use the +1 accordingly.

Apple. So easy to use....

[CritterNYC]

iTunes.pkg *click-click*

"Ah... Apple... So easy to use, now wonder it's number on.."

*quack* *quack*

"what?... huh?... oh, son OF A BIT#$%!"

Re:*sigh* Amateurs...

[B'Trey]

Given today's optimizing compilers, the two are probably functionally equivalent.

Have EULAs been tested in court?

[Greyfox]

There are a lot of questions that arise with EULAs. I seem to recall a click-through EULA on a web page being rejected by a court. Maybe it'd be a good time for a legal-system test.

Even if the court says the data on the drive should have been backed up, you should be compensated for time spent restoring that data, reinstalling the OS, and generally getting the computer back in shape. Not to mention the woeful negligence factor as a simple test should have uncovered this problem prior to the product being released. An application install should not wipe your hard drive out.

As usual, IANAL (But I play one on TV)

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

Re:Sue them.

[Dyolf Knip]

Its a virus - it hides behind a legitimate program, performs some sort of check, then delivers a payload. If thats not a virus, then i don't know what is. Just because Apple may 'claim' its a mistake, is no excuse. People have gone to prison for less so i say, give them a big fat law suit.

Are you listening to yourself?

He's right to some extent. A bug that causes a program to crash is perfectly ordinary, if annoying. One that 'oops, we just wiped out your entire hard drive, so sorry' is totally unacceptable. Hell, most viruses aren't even designed to be that bad. Software can always be expected to be buggy, but this crossed the line between 'not quite enough debugging' and criminal negligence on Apple's part. Prison is a bit much, but financial liability is quite reasonable.

Re:The big mistake here...

[fwr]

I'm a little confused, because I'm not an Apple user at all, but I thought that the base OS was similar to Linux as to it's kernel module capabilities. If so, then there shouldn't be any reason to require the modification of "system" directories. You should be able to load a driver for various CD's from any directory. The module loader program may require root privelages, but there shouldn't be any reason that the modules themselves need to be in a particular directory. Or, is OS X not capable of doing this?

/. said something bad about the iPod? hells yeah.

[Geek Dash Boy]

And there was a /. story about the iPod - and it had nothing bad to say about Apple

Go back and read it again. There's a negative comment by Taco in the initial post.

Slashdot is inherently anti-Apple due to the attitude of editors which is quickly imitated by the troll hordes and flamebaiters. 'cuz everyone knows the easiest way to generate wind is to get a bunch of Mac zealots in one place and say one bad thing about Apple or the Mac OS.

For the record, I'm a long-time Apple customer that got tired of the OS wars a long time ago. I'd much rather be coding in my very nice Mac OS X setup, thank you very much.

Survey says...

[doorbot.com]

Interestingly, there is some logic beyond this argument as well.

Assume for a moment that you're a hard working, productive worker building your product or otherwise producing more income to the company than they pay you. You are a "good" employee, and the company would prefer to keep you. Now, another employee who was hired along side you is promoted to your manager. But you reflect back at all the asinine questions that person asked, and how perfectly obvious they made the fact that they should be working at McDonalds and not making $100,000 a year bossing you around (let alone in this industry).

Why did they get promoted? Is it because they're buddies with the boss? It is because everyone is in some maniacal conspiracy against you?

No. It's because of two things. Either they get promoted, or they get fired. Sometimes a company will chose to promote rather than fire an employee. But more likely, the simple fact is that you are productive in your position. If you were to be promoted to manager, your job would radically change and the company would not have the benefit of your skills working towards completion of the product.

That's why most management is "stupid" and "doesn't get it." Because they were workers who were stupid and don't get it. Granted, there are some members of management who are good at what they do -- these are the few that won't get fired when management has its shakedown. And not everyone is promoted to management... but if they were hired on, does that necessarily make them good at their job?

Think about it, if management were that great, it'd cost a lot more.

Kernel modules

[hearingaid]

Disclaimer: I don't run OS X, and I've never configured a Linux kernel.

However, I have configured FreeBSD kernels. And in FreeBSD, some kernel modules are externally loadable, but they always need hooks into the compiled kernel (and it's generally better to put the kernel modules you always need directly into the /kernel file, that way you don't need to do so much disk access)... And, so far as I know (I haven't installed any FreeBSD past 4.0), device drivers are not hookable in any version of FreeBSD. IIRC OS X & FreeBSD share a lot of kernel traits in common, this I would expect to be one of them.

Re:How to do it

[stripes]

Rather than having the script delete iTunes.app, have it move it to the appropriate .Trashes folder.

Ok, that's a good idea. There are a few problems with it, but I think they are smaller the the problems with real removal.

• I think iTunes (the old one) is probbably owned by root, so I'm not sure it would go to the current users trash, or work well there unless chown'ed. If it gets chown'ed just dragging it back where it was might not be a good idea (if nothing else it means an attack on user Foo can overwrite itunes and if someone elses runs it sneak in...; not a big deal since user Foo had to be an admin to install iTunes2 anyway). However untangling that kind of mess is better then dealing with half (or all) your files being rm'ed
• There may not be enough space to install unless the old iTunes is deleted first, which would frustrate people.
• More crap in my trash can? Have you seen how full the thing is already?
• There is no easy way to invoke the Finders "move to trash" from a shell script. It would be a fine idea to fix this problem.
• From a UI point of view I'm not sure people would expect upgrading some software to leave the old version on the trash. Of corse two years after we start doing it that way everyone will expect it, and think it would be dump not too...

Very good idea. Someone tell Apple :-)

P.S. it is owned by root: drwxrwxr-x 3 root admin 58 Nov 3 17:30 /Applications/iTunes.app/.

Re:The big mistake here...

[jcr]

It sounds like you aren't familiar with what iTunes does.

If it sounds like that to you, then your hearing is faulty. iTunes should be a self-contained .app, which any user can install in /Applications, ~/Applications, or anywhere else you care to. If it requires a framework or a .kext to talk to the CD/RW drives, then those should be in separate package which require root priveleges to install. In fact, the drivers should be obtained through the Software Update mechanism.

-jcr

Misleading statements

[FastT]

This is a chronic problem that most commercial software houses have.

While technically true, the connotation of your statement and the statements that follow are misleading. Sure, the state of testing is poor in commercial software, but it's even worse in open source software. At least commercial companies provide some minimal testing with each release, actually have people assigned and paid to do testing, and have someone to call when you have a problem. Compare this with the schlock you get with most open source software, which was at most tested on nothing other than the author's machine, with no code review, no test cases, and no accountability.

Of course, there are some open source exceptions, just as there are in the commercial world. But remember that 99.9% of open source software is NOT Apache or Linux, and the people developing the rest of this software are frequently more enthusiastic than skilled, and definitely have no resources dedicated to testing. In fact, many open source developers are also commercial developers who prefer to work on open source because they can work alone and it doesn't come with all the "crap" like code reviews.

So, let's lay blame where it belongs--on software development in general, the lack and/or cost of resources, and the general disregard for software quality as something important. None of these things are limited to commercial software development.

Re:OS 9 Forever!

[stripes]

perhaps some lunitic will come up with a nice OS 9.2.1 theme and theme manager to run it over aqua for you

If you look over on MacNN someone has one fairly far along. I think the only big chunk o' work they have left is the scroll bars. I think it was a Friday headline.

The NASA model is not commercially viable

[Ars-Fartsica]

Sorry, but if you try to push out software using the NASA model, you will be late to market and ultaimtely out of business.

Rapid deployment and subsequent revisioning is the secret behind many of the largest software companies in the world.

Ultimately you have to sell a product and pay your employees, and the NASA model is never going to do that.

Possible fix?

[mr100percent]

Anyone having permission problems, or thinking they lost a hard drive: Logout, then login as ROOT. Hopefully you can now see all contents of your hard drive again. Go to your hard drive(s), right click and select Show Info. Go to Privileges in the drop down. Change the selection EVERYONE to READ & WRITE. Click Apply to All Enclosed Folders. Wait while it copies the privileges. Now logout and login as yourself. See if that resurected your data

See if that's it. I heard of it on Macnn.com forums. You may have a chance...

Re:Ahh... Imagine if this were a Microsoft product

[spitzak]

The bug only destroys partitions that are mounted. Unless the Linux partition can be mounted (can OS/X do this yet?) it would be untouched.

If I understand the bug right, if you have Itunes installed on a disk named "foo bar" (with a space in it) *and* you have a disk named "foo" (ie it matches the part before the space) the "foo" disk is wiped with the Unix rm -rf command.

You weren't paying attention.

[jcr]

Oh, and I'd love to hear how making the package containing the burning framework a separate item would solve this problem. That would simply move the buggy pkg file to another place.

The problem wasn't the framework, it was a bug in the installer script. NeXTSTEP, and the first version of Mac OSX Server had an installer app, based on tar.gz files, that never exhibited this kind of problem.

Why Apple abandoned tar for pax, we're all still wondering. You can find a detailed explanation of exactly how Apple botched the installer system in Mac OS X on stepwise.com. Search the site for "pax".

-jcr

Re:You weren't paying attention.

[Apotsy]

The installer script was in the .pkg file, hence the words "buggy pkg file" in my above post.

You started this thread by saying iTunes shouldn't need an installer, but several people rightly pointed out why one is necessary. You then implied that putting the system-level frameworks iTunes depends on into a separate installer would somehow have prevented the problem, which it wouldn't.

You finally got something right by saying it was a bug in the install script, but you still don't seem to grasp the facts that 1) The install script is necessary and 2) Making it a separate install from iTunes would not prevent bugs in said install script.

It seems you're the one who wasn't paying attention.

Power Tools can kill!

[dublin]

Ah, I see, you live by the "tough man" approach to programming. The fact is, people keep shooting themselves in the foot with this.

Some truths just stubbornly remain the same: Unix and its derivatives are great because they are power tools - but always remember, "Power tools can kill!" (If they couldn't, they wouldn't be power tools, anymore, now would they? For a great insight to this important aspect of the Unix philosophy, do a net search for Neal Stephenson's "In the beginning, there was the command line", and his quite apt comparison of Unix to the amazingly powerful Milwaukee HoleHawg, which is, as the saying of aviation goes, "terribly unforgiving of any carelessness, incapacity, or neglect."

Why is this on Slashdot?

[TheInternet]

Am I the only one that the fact this gets an entire topic to itself is a little weird. Maybe in a "quickies" or something...

- Scott

Even better

[mr100percent]

Call Apple, they'll reimburse you for the cost of norton utilities or a disk recovery.