iTunes 2 Installer Debacle
The weekend of 03-Nov-01 was a bad one for Apple and some early users of iTunes 2. After releasing the new version late Friday night, Apple hastily pulled the Mac OS X installer Saturday morning due to a problem where, in some situations involving multiple volumes named in specific ways, the installer could delete a large number of files. Needless to say, this is a bad thing, and there have been reports of Apple quietly offering to buy file recovery software or even pay for DriveSavers recovery of affected hard disks. A revised installer, with the designation iTunes 2.0.1, was released before the end of the weekend.
<http://www.apple.com/itunes/alert/>
<https://tidbits.com/getbits.acgi?tbart=06616>
<http://www.drivesavers.com/>
The specifics of how this happened have been discussed at length in TidBITS Talk and similar forums, but roughly speaking, the installer Apple used to install iTunes in Mac OS X apparently relied on a shell script that assumed the previous version of iTunes would be in the Applications folder. Since everyone’s disks have different names, the script figured out the name of the disk, appended the path to the iTunes application, and then deleted all the files in the iTunes folder. Unfortunately, the script didn’t take into account the fact that people might put spaces in their disk names, particularly that they could put spaces at the beginning of the disk name. Since the space separates arguments in Unix commands, a command that would delete a single file is suddenly broken in the middle, transforming it into a command that can delete an entire disk. The problem can be avoided in Unix merely by enclosing the command in quotes, but that didn’t happen initially.
<https://tidbits.com/getbits.acgi?tlkthrd=1515>
It’s easy to blame Apple for sloppy work and to bemoan the loss of data by innocent users. But I think this event points out a number of deeper issues that underlie the entire move to Mac OS X, showing precisely where Apple needs to work at a variety of levels, including the cross-pollination of Unix and Macintosh knowledge, the use of appropriate installation technology, and the crying need for backup support.
Mac Plus Unix — Much has been made of the schism between Macintosh and Unix, with Apple saying that you won’t need to know any Unix to use Mac OS X and Unix geeks gleeful about getting an operating system that can run both Unix software and mainstream productivity applications. What this installer debacle shows is that Mac OS X developers and experts alike will have to be fluent and comfortable in both the Macintosh and Unix worlds. Look at the mistake that was made in the Mac OS X iTunes installer to see why.
From one point of view, the person who built that installer was clueless about Unix. Anyone with any real Unix experience knows that you have to quote Unix pathnames that contain spaces, but that’s something a Macintosh user would never even consider as a concern. However, it’s equally easy to surmise that the person responsible for the installer had no idea that normal Mac users are perfectly capable of naming hard disks with spaces – even leading spaces – not to mention untold other troublesome characters like leading hyphens. A Unix person would never consider doing such a thing.
It doesn’t really matter which possibility was true in this case – my point is merely that without widespread knowledge of both operating systems, and beyond the operating systems to the usage conventions and opportunities afforded by each, mistakes like this will continue to happen.
Installation Automation — I may be giving too much emphasis to the lack of knowledge on the part of the person who built the installer – it’s entirely possible this person is the pinnacle of both Macintosh and Unix knowledge and made a simple, human mistake. It happens to all of us, and it’s certainly easy to imagine the omission of a few quote characters. This raises two points.
Why did Apple choose to use its own installer with a hand-written shell script, where there’s no pre-tested code and interface that works to avoid simple human errors? Keep in mind that this is the installer that already has several black marks against it (one relating to passwords with unexpected characters, another with blown permissions).
<https://tidbits.com/getbits.acgi?tlkmsg=10775>
<https://tidbits.com/getbits.acgi?tbart=06415>
What’s especially ironic here is that Apple used MindVision’s Installer VISE for the Mac OS 9 iTunes installer, which would have lowered the effort and costs of building a Mac OS X version of the installer. Installer VISE could even have distributed both the Mac OS 9 and Mac OS X versions as a single installer file, installing appropriately depending on the operating system in use. It’s certainly conceivable that someone could have made a similar mistake with Installer VISE, since Installer VISE can pass installation paths to Unix shell scripts, but there wouldn’t be any need to write those shell scripts. One way or another, Installer VISE is a long-standing, heavily used installer that’s been tested both by MindVision and a veritable army of Macintosh developers while building installers for thousands of products. As all Mac software should, Installer VISE goes out of its way to make sure the right thing happens. The same is certainly true of Aladdin’s InstallerMaker, which I used back when I was creating installers for my books.
<http://www.mindvision.com/>
<http://www.aladdinsys.com/installermaker/>
I’m sure there are numerous possible reasons Apple chose its own installer, including pride, the dreaded "Not Invented Here" syndrome, the fact that Installer VISE comes from the Mac world instead of the Unix world, and even the laudatory goal of using one’s own tools – "eating your own dog food," as it’s called in the industry. The specific reason doesn’t particularly matter; what matters is that Apple learns to focus primarily on what’s important for customers. If it’s too easy to cause data loss using the Apple installer, that’s a problem. It’s possible that the just-released Installer Update 1.0 (available last Thursday, via Software Update) will help, since it "delivers improved support for installing software updates and is required for any future Mac OS X updates." Unfortunately, we have no way of knowing, since the phrase I quoted above is the sum total of what Apple’s saying about the improvements. And, not that it really matters for this discussion, why didn’t Apple release iTunes 2 via Software Update?
Where’s Your Backup? Perhaps the most commonly uttered platitude in the computer industry is, "Make sure you have a backup, then…" We’ve said it innumerable times in TidBITS, and it’s standard advice when installing new software. Of course, no one should be making a backup specifically to prepare for installing software – you should have a backup strategy that ensures you’re adequately protected at any given time.
The big problem is that you still cannot back up a Macintosh running Mac OS X easily, reliably, and automatically in such a fashion that you can restore the entire machine to working order in the time it takes to read the files from your backup media. Yes, there are some ways of copying important files to another hard disk or machine over the Internet. But there is no way to implement a real backup strategy right now, which involves automated backups that run on a regular schedule, copy only changed files, preserve all permissions and file attributes, and keep different versions of the files. Backup software running in Mac OS 9 or under Classic cannot back up all Mac OS X files such that they can be restored properly, and even the public beta of Dantz Development’s Retrospect Client for Mac OS X has troubles under Mac OS X 10.1.
<https://tidbits.com/getbits.acgi?tlkthrd=1510>
<http://www.dantz.com/index.php3?SCREEN=osx>
Apple simply hasn’t devoted the resources necessary to making it possible to perform backups because backups aren’t sexy, don’t sell boxes, and imply that data loss is likely. Realistically, though, data loss isn’t a question of if, it’s a question of when – at this point, the main reason I refuse to install Mac OS X 10.1 on my primary Mac is that I can’t back it up acceptably. Those who lost data because of the poorly written iTunes installer would have been annoyed at the loss even if they’d had backups, but the damage wouldn’t have been nearly as great. These people didn’t have backups (or at least good backups), and this time it’s not just a case of the user being lazy or tempting fate. This time Apple deserves the lion’s share of the blame for creating an operating system that can’t be backed up and restored reliably many months after the initial release. For this reason alone, Mac OS X cannot be considered acceptable for serious use in many situations.
Lessons — In the end, it’s worth remembering that getting everything right all the time is near-impossible, and Apple at least reacted quickly to the problem, pulling the Mac OS X iTunes installer and posting a warning. What’s most important is that Apple learns from this mistake so something similar doesn’t happen again. Can you imagine the fallout if this particular problem had been on all the Mac OS X 10.1 CD-ROMs?
For Apple, then, I’d recommend the following:
Encourage the cross-pollination of knowledge between Mac and Unix experts, both inside and outside of Apple.
Use an installer technology that works to reduce the likelihood that a simple human error could cause data loss and increase testing on any installer that can delete files.
Make it possible to perform real backups of Mac OS X machines as soon as possible.
For the rest of us, I recommend waiting a few days before installing any updates. Others will always be more brave (or foolhardy), and the more patient among us should learn from their experiences.