Hide full article
Here's the good news. Mac OS X doesn't suffer from the same sort of conflicts that Mac OS 9 did. You will seldom, if ever, find that installing a new piece of software causes some other program to act in an unnatural, demon-possessed fashion. Apple promised that level of reliability, and they delivered.
Now here's the bad news. Mac OS X has its own soft underbelly, and an appropriate bit of file corruption in the wrong place can cause all sorts of wacky problems that can be devilishly difficult to track down. Here are a few quick examples I've experienced.
When I upgraded Tonya's Power Mac G4 (QuickSilver) to Jaguar, using the Archive & Install option to get a nice clean version, the Finder would launch, then quit, launch, then quit. The Mac was unusable, or it would have been if Tonya hadn't had a second user account that she used for documentation. When I logged into that second user, everything worked fine. To make a long story short, I discovered that moving Tonya's ~/Library/Preferences folder out to the Desktop and logging in again solved the problem (remember from Kirk McElhearn's command line articles that the ~ is a shortcut for your user's home folder). Then, a note from Fetch author Jim Matthews on a mailing list I'm on saved me from the tedious effort of tracking down the culprit, which turned out to be the com.apple.LaunchServices.plist file. I logged in as the root user, deleted that file, and Tonya was able to log in to her Mac again. Marital strife ("You did what to my Mac?!?") narrowly averted!
<http://db.tidbits.com/series/1238>
This turned out not to be an isolated incident. Aside from Jim having had the same problem, when my parents upgraded their Power Mac G4 Cube to Jaguar, the problem happened again with my mother's account, necessitating an unscheduled evening visit to restore the Mac to working order. Once again, I enabled the root user, deleted com.apple.LaunchServices.plist, and the problem was gone. It even renewed my parents' faith in my skills and their belief that my expensive education hadn't been for naught. Phew!
A similar problem appeared on my Mac recently as well. I wrote about the Maxtor Personal Storage 5000 FireWire hard drives for Macworld a few months back because the Maxtor drives have this neat button that, when pushed, launches Retrospect Express and performs a backup. But at some point, well after I'd handed in my review to Macworld, the buttons on a pair of Maxtor drives stopped working, first when using my iBook and somewhat later on my Power Mac G4. Eventually I managed to get in touch with the right people at Maxtor, and after they were unable to reproduce the problem, it was escalated to the programmer who had written the driver for the button, John Brisbin. John and I verified that everything was installed correctly, and that the driver and notification application were loaded and running, but it still wasn't working.
<http://www.maxtor.com/en/products/external/ personal_storage_5000/>
Then came the moment of insight. John had me check to see if the Retrospect Express plug-in that did the work was set to launch Retrospect Express in the "Open with" pane of the Get Info window. It wasn't... on either machine, and in fact, the pop-up menu offering other choices for programs that could open the plug-in contained utterly random files that weren't even applications. On his recommendation, I first threw out my user's ~/Library/Caches/com.apple.LaunchServices.UserCache.csstore file, which is a cache of file types that are associated with specific applications for the user, and when that didn't help, I tossed /Library/Caches/com.apple.LaunchServices.LocalCache.csstore, which is the system-level cache of associations that apply to all users. A restart was necessary at that point, but when the Mac came back up, the plug-in knew it was linked to Retrospect Express again, and the button worked perfectly.
Two final minor examples. Just a few days ago, someone complained to me that iPhoto wouldn't show his Keywords window, and another person complained that their copy of iPhoto no longer played slideshows. In both cases, throwing out the com.apple.iPhoto.plist file in ~/Library/Preferences eliminated the problem instantly.
Why We Need Conflict Catcher -- You can see where I'm going with all this. We may no longer have conflicts between programs in the same way we did with Mac OS 9, but it's clear that Mac OS X and its applications are just as vulnerable to problems in their support files as they ever were. There's nothing new here - corrupted preferences files caused all sorts of problems in Mac OS 9 too.
What has changed is that Mac OS X has so many more files, and stores them in so many more locations, that it's difficult to determine where the problem may lie. Let me tell you another story that illustrates this.
A few days ago, the text in my Eudora toolbar and InDesign palettes, both of which use the Geneva font, suddenly became horribly ugly and jagged, although Geneva-formatted text in other applications looked fine. I didn't do anything that could have caused that change as far as I knew, so I immediately chalked it up to a corrupted preference file or font cache file. Logging into the second user on my Mac proved that the problem was related to my user's settings, since the problem didn't occur in Eudora or InDesign for that user.
But then I spent about 45 minutes pulling preferences files, fonts, cache files and more, all in vain. I even extracted my user's entire Library folder and let Mac OS X rebuild a new one; no change. The entire process was becoming highly frustrating, as I had to make a change, log out, log back in, launch InDesign, verify the problem still existed, and move on to the next test. I consulted Ted Landau's excellent book, Mac OS X Disaster Relief, which suggested deleting the system font cache. Even that didn't help. Finally, while reading Ted's discussion, I had the brainstorm that perhaps something had happened to my font smoothing settings. That was it - somehow the "Turn off text smoothing for font sizes" setting in the General preferences pane had been reset to 9 point, whereas it had to be set to 8 point for Eudora toolbars and InDesign palettes to look good. All my rebuilding of preferences files didn't help because it kept going back to 9 point. If I'd had a tool like Conflict Catcher that could have eliminated all the preference and cache files from the equation quickly, troubleshooting wouldn't have taken nearly as long.
<http://www.amazon.com/exec/obidos/ASIN/ 032116847X/tidbitselectro00>
I hope all these stories make it clear why we need a utility that can automate standard troubleshooting procedures. In short, we need Casady & Greene's Conflict Catcher, but we need it for Mac OS X. Conflict Catcher has basically all the necessary functionality for Mac OS 9, and as much as I'm sure people thought it wouldn't be needed under Mac OS X, recent experience shows the opposite. For those that aren't familiar with it, Conflict Catcher speeds up troubleshooting conflicts in Mac OS 9 by moving files out of functional folders (Control Panels, Extensions, Fonts, Preferences, and any others you specify) to disable them. Then you reboot, verify if the problem exists or has disappeared, and continue the process. Conflict Catcher keeps narrowing the set of possible culprits until, after some number of reboots, it can point the finger directly at one or more problematic files. Obviously, Conflict Catcher in Mac OS X would have to look at various different preferences and cache folders, act as root to move certain files, and automate the verification step, but those are all functions that the program had under Mac OS 9.
<http://www.conflictcatcher.com/>
Automating the process of disabling and re-enabling files isn't rocket science, and an enterprising shareware developer could easily step into the gap here. It would be great to go beyond what Conflict Catcher could do and apply some intelligence to the otherwise brute-force process as well, so you could say that your problem related to iPhoto, for instance, and it would take a quick first pass on disabling those files most likely to be related to iPhoto. We'll be discussing what such features a troubleshooting tool should have on TidBITS Talk; feel free to join in.
<http://www.tidbits.com/search/talk.html>
Go to the Root -- While we're on the topic of troubleshooting, let's talk briefly about the root user that figured in my first two examples. For those who don't know, the root user is a user that exists on your Mac and that has access to every file. There's nothing the root user can't do, and that makes it as dangerous as it is useful. When you're logged in as the root user, nothing prevents you from deleting even files that Mac OS X needs to operate. So, although it's reasonable to use the root user on occasion, it's important that you do so only when necessary, and leave it disabled the rest of the time.
How do you access the root user? Launch NetInfo Manager from the Utilities folder inside your Applications folder. From the Security menu, choose Authenticate, and enter your administrator password. Go back to the Security menu and choose Enable Root User. If necessary, NetInfo Manager prompts you to give the root user a non-trivial password. Open System Preferences, click the Accounts icon (not My Account!) and turn off "Log in automatically" (you may have to click the lock button at the bottom to make changes). Turning off automatic login isn't necessary, but I find it's a good reminder to disable the root user when you're done. Now log out, and in the login window, log in as "root" (you may need to click the Other button to get username and password fields). Once you're logged in as root, you can delete files in any user's folder, so be careful. Do what you need to do, log out and back in to test your changes, and then disable the root user in NetInfo Manager by choosing Authenticate from the Security menu, entering your administrator password, and choosing Disable Root User from the Security menu. Then return to the Accounts preferences pane and turn automatic login back on if you want.
For those Unix-heads wondering why I chose to enable the root user in NetInfo Manager rather than use the sudo command from the command line to delete the offending file, in both of these cases, I didn't know exactly what file to delete at first, and I needed the flexibility of the Finder. Had I known for sure what I had to do, the command line might have been faster.
Split Personalities -- I want to leave you with a recommendation I now make to everyone who uses Mac OS X. These and other problems have convinced me that you simply must create another user on your system with administrator privileges. You don't have to use it for anything other than troubleshooting, and in fact you shouldn't use it much at all. I call mine "Ghost in the Machine" (ghost for short), and I give it the same password as my main account so I don't forget it.
When you're faced with some sort of a problem, log out, and log into your ghost account to see if the problem is still there. It's a lot like holding down the Shift key in Mac OS 9 to boot without extensions. If the problem is gone, you know it's somehow specific to your user, which lets you limit your troubleshooting to files that could affect only one user on the system (basically, look in your ~/Library folder). If the problem still exists, you know it's not limited to your user, and you should look higher up, such as in /Library and /System/Library).
If you can tell that a problem affects all users, it's worth rebooting with the Shift key down to perform a Safe Boot and put Mac OS X into Safe Mode, which does a number of things. First, Safe Boot forces a disk check equivalent to using Disk Utility's Repair Disk function or booting in single user mode by holding down Command-S at startup, then entering "fsck -fy" at the command line. Safe Boot also loads only required kernel extensions and runs only Apple-installed startup items in /Library/Startup Items and /System/Library/Startup Items (note that these startup items are different from login items, which are applications and documents opened at startup by each user). There's no need to run in Safe Mode normally, but it's a handy way to perform a disk check and verify that no third party kernel extensions or startup items are causing your problems.
The problems we encounter in Mac OS X may be new, but the ways we troubleshoot those problems remain much the same. All we need is the knowledge of how to apply those troubleshooting methods and the tools and techniques to make troubleshooting something anyone can do. Otherwise, many people will be echoing my father when he asked, "And just how would we have fixed this problem if you hadn't been around?"
PayBITS: Are Adam's troubleshooting tips in this article going
to save your bacon someday? Say thanks in advance via PayBITS!
<https://www.paypal.com/xclick/ business=ace%40tidbits.com>
<http://www.amazon.com/paypage/PJY14IW7KVKSN>
Read more about PayBITS: <http://www.tidbits.com/paybits/>
