• The Tiger Report: The Great Repair Disk Permissions Mystery

    May 21st, 2005

    Whenever something goes wrong with your Mac, you feel comfortable with an easy solution. Back in the days of the Classic Mac OS, the pat answer when your system began to crash more frequently than usual was to rebuild the desktop. So what did that accomplish? Well, the desktop database was used to store file icons and the links from documents to the applications that made them. If the database got corrupted, the icons might become generic or, worse, the wrong applications would open. Maybe you’d open a Word application and get Photoshop; maybe.

    In theory, if the database became damaged, system crashes might result. But it’s a symptom seldom, if ever, realized, but that didn’t stop some people from suggesting the desktop rebuild at even the hint of trouble. After all, it didn’t hurt, right? In fact, at one time the Mac support volunteers at AOL were told to deliver this answer as a standard troubleshooting step, even if it had nothing whatever to do with the problem. And that’s even before AOL lost whatever luster it had.

    For Mac OS X, the closest thing to a desktop database is something called Launch Services, and it determines what applications will open when you double click on a document. But you seldom hear about rebuilding that database when things go astray in Mac OS X. Instead, you repair disk permissions.

    Under Mac OS X files are granted rights specifying whether you, the system or other uses can read or write to them. If the permissions get wonky, the theory goes, system problems may result. Applications might crash, for example. Since Apple’s Disk Utility offers a Repair Disk Permissions feature, there appears to be nothing wrong in using it. In fact, some suggest you run this process before and after installing new software. Maybe repeat the process every few days. Officially, Apple explains what it’s all about in a Knowledge Base document.

    But does it do any good? That is the topic of a lengthy article from “Rosyna,” one of the lead programmers at Unsanity, a company that builds Mac OS X system enhancements. The conclusion from this verbiage explosion is that “repairing permissions is useless 99.9% of the time. Permissions don’t magically go bad. And you should really throw out ‘repair permissions’ as a troubleshooting step until you’ve exhausted all other methods of troubleshooting.”

    As you know, there are several utilities out there that perform a number of Mac OS X maintenance functions, including repairing disk permissions. Some, such as Tom Harrington’s Macaroni, can even perform that repair on a scheduled basis. So is it, as Rosyna concludes, a waste of time?

    I asked Harrington and several other developers of such utilities for comments, and Harrington’s is not only the one that arrived first, but the most detailed. I only have time to excerpt some of the salient points, but this should be enough to give you a good idea of where he’s coming from. For example: “The first thing that catches my eye here is the statement that ‘…repairing permissions is useless 99.9% of the time.’ Wearing a seat belt is useless 99.9% of the time as well, but I’m not going to stop wearing one.”

    But that’s just the beginning. He tears Rosyna’s article from stem to stern, beginning with this significant point: “The explanation there is based partly on a misunderstanding of how permission repair works.”

    Wow! So how does it work?

    Harrington writes, “Specifically, early on it states that ‘Repairing permissions goes through all the Package files (.pkg) in /Library/Receipts/.’ This is not correct. It’s true that the information used in permission repair is found in installer receipts, however it’s not true that all receipts are used. In fact a strictly-defined set of receipts are consulted, and others are ignored…what it comes down to is that only receipts for software installed by Apple are consulted. That has an advantage in that a buggy installer shouldn’t prevent permission repair from getting crucial system files back to their normal state, but also a disadvantage in that third-party software won’t get repaired.”

    Now I’m going to avoid some of the technical details that may just bore or befuddle the non-programmer and concentrate on more practical matters. Thus, “As for the comments about repairing permissions both before and after installing a Mac OS X update, I generally agree. That kind of advice has the whiff of snake oil to it. This is especially true in the case of a major upgrade (such as to Tiger)–if you’ve booted your Mac from a CD or DVD, the upgrade process won’t be affected by whether the permissions on your hard drive are correct. I don’t generally bother with this myself, but then since I use Macaroni to run my system maintenance, I always know that permission repair has been run recently, if not necessarily today.

    “Despite this, though, I’m surprised that the author says that this advice ‘…really boils my blood.’ The steps might not be necessary, but they’re not harmful either. Anyone who gets this upset over the advice should probably consider switching to decaf, or at least getting out into the sun once in a while.

    “Finally, in the original article, the author advises that many Mac problems–including those related to permissions–can be more effectively solved by going to the system console and looking for relevant details. Speaking for myself only, I agree. But then, I’m a longtime Unix geek, so this comes naturally to me. Most Mac users are not Unix geeks, and if you send them to the console, their eyes will quickly glaze over at what they see as impenetrably cryptic text. I don’t mean that as a put-down; we all have our own strengths and weaknesses, and it’s not reasonable to expect everyone to grasp what’s going on there. I’m all for user education, but sending people to the console as a solution is simply not an effective approach in most cases.”

    So is repairing disk permissions a placebo? No, but it’s not a panacea either. Now let me get back to my morning cup of java.

    | Print This Article Print This Article

    Leave Your Comment