Forgot your password?
typodupeerror
Apple Businesses

iTunes 2.0 Installer Deletes Hard Drives 511

Posted by michael
from the making-room-for-more-mp3s-i-guess dept.
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.
This discussion has been archived. No new comments can be posted.

iTunes 2.0 Installer Deletes Hard Drives

Comments Filter:
  • by dimator (71399) on Sunday November 04, 2001 @04:12AM (#2518193) Homepage Journal
    Well, here's the pseudo-code:


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


    Hard-to-spot bug, actually.
    • by 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);
      • 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.
    • by Anonymous Coward on Sunday November 04, 2001 @09:18AM (#2518563)
      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.
    • by Phil Wherry (122138) on Sunday November 04, 2001 @12:30PM (#2518984) Homepage
      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."
  • by Anonymous Coward on Sunday November 04, 2001 @04:12AM (#2518196)
    Rip. Mix. Burn. Format. Reinstall.
  • Liability (Score:2, Interesting)

    by jeti (105266)
    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 (Score:3, Interesting)

      by wrt (530301)
      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.
    • 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.
  • Oh, come on... (Score:2, Interesting)

    by CrayBeast (521458)

    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... (Score:5, Insightful)

      by GISboy (533907) on Sunday November 04, 2001 @11:01AM (#2518779) Homepage
      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
      • 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.
    • Re:Oh, come on... (Score:3, Interesting)

      by Greyfox (87712)
      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 (Score:2, Redundant)

    by Kira-Baka (463765)
    http://newforums.macnn.com/cgi-bin/ultimatebb.cgi? ubb=get_topic&f=46&t=000865

    It has some info about causes and solutions...
    • Actually, your URL has a space too many. Here's one that works:

      Link [macnn.com], 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 (Score:3, Informative)

    by Anonymous Coward on Sunday November 04, 2001 @04:22AM (#2518222)
    Apple has already put iTunes 2.0.1 that purportedly takes care of the problem:

    http://www.apple.com/itunes/download/
  • by sakusha (441986) on Sunday November 04, 2001 @04:27AM (#2518233)
    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.

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

        • 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);

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

        • 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
    • 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).
  • Wide spread? (Score:2, Interesting)

    by panZ (67763)
    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? (Score:3, Insightful)

      by moof1138 (215921)
      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.
  • The bug (Score:5, Interesting)

    by hysterion (231229) on Sunday November 04, 2001 @04:39AM (#2518251) Homepage
    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.
    • quote (Score:4, Informative)

      by Jotham (89116) on Sunday November 04, 2001 @04:53AM (#2518274)
      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 [macslash.com] (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

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

      • by Gid1 (23642)
        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.

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

    • "...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.
  • Free Format (Score:2, Funny)

    by starphish (256015)
    I've been looking for a good free format utlity with an attractive front end. Is there a PC port?
  • mmm... (Score:2, Troll)

    by Wakko Warner (324)
    ...smell that? that's a steaming heap of Apple quality.

    - A.P.
  • 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
    • by Detritus (11846) on Sunday November 04, 2001 @06:27AM (#2518382) Homepage
      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.
      • by Carnage4Life (106069) on Sunday November 04, 2001 @08:46AM (#2518526) Homepage Journal
        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 [slashdot.org] 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.
        • 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.

      • 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?
    • 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)

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

  • Nature of the bug (Score:4, Redundant)

    by HalfFlat (121672) on Sunday November 04, 2001 @04:52AM (#2518270)

    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.

    • by mj6798 (514047) on Sunday November 04, 2001 @07:36AM (#2518456)
      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.

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

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

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

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

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

      • I believe that filenames can even include /. Shells might not like it, but Unix filesystems don't care.
        • 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.
    • 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

  • 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.
  • 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.
  • by Lord_Pall (136066) on Sunday November 04, 2001 @08:13AM (#2518485)
    So i guess the Ipod/Itunes combo really IS a killer app.

  • by jht (5006) on Sunday November 04, 2001 @08:14AM (#2518487) Homepage Journal
    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..
    • 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.
  • by IRNI (5906)
    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. (Score:3, Interesting)

    by prwood (7060) on Sunday November 04, 2001 @09:56AM (#2518643) Homepage
    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?
  • 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 (Score:2, Funny)

    by dbretton (242493)
    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....
  • But what kind of drive/storage device did you have that had 100GB on a partition?
  • 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"
  • 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#$%!"
  • Possible Fix... (Score:4, Informative)

    by DragonPup (302885) on Sunday November 04, 2001 @12:50PM (#2519038)
    Andrew Welch of Ambrosia Software [ambrosiasw.com] posted a method that MIGHT work on recovering the files here [macslash.com]. 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

"In the face of entropy and nothingness, you kind of have to pretend it's not there if you want to keep writing good code." -- Karl Lehenbauer

Working...