Originally posted by Matthew64
Make this a standard proceedure when installing ANY Apple update:
1) Run Repair Permissions in the Disk Utility before installing
2) If it is a major OS update, download the combo update when it is available instead of using Software Update.
3) Run Repair Permissions again after the update is successfully installed.
That is, if you want to completely waste your time.
1. Running Repair Permissions before installing is not going to make one bit of difference. Software Update runs as root, and it does give a damn what
the permissions are on the drive. This step literally does absolutely nothing for you.
2. All Repair Permissions does is make sure the permissions of files on your disk are the same as the permissions that are set in the packages in /Library/Receipts. Plus, there's no One True Way that the permissions need to be for most files. While running Repair Permissions after an update will turn up a list of files that got changed, just because the permissions for a file may be different in the software update you just installed does not necessarily mean that those permissions are wrong.
So the permissions for /private/etc/slpsa.conf are -rwxr-xr-x in BSD.pkg but -rw-r--r-- in MacOSXUpdate10.3.8Patch.pkg. Does that mean the 10.3.8 package is wrong? Both sets of permissions work.
Repairing permissions after an Apple software update is only important if you think Apple would be incompetent enough to release an update with completely FUBARed permissions. I think Apple is better than this, people. In fact, I'd be more inclined to trust the permissions on their newer
updates than their older ones, since they could have found a mistake and fixed it in a later version. For example, that slpsa.conf file I mentioned above, which incidentally was the only file that Repair Permissions found with changed permissions when I ran it. The 10.3.8 package says -rw-r--r--. Doesn't that make more sense than -rwxr-xr-x for a configuration file? Why does the executable bit have to be set on that file? It's not a binary or a shell script, it's just a configuration file! Seems to me that someone at Apple actually noticed this was wrong and fixed it, only to have Repair Permissions set it back to the way it came in 10.3.0 or whatever version of Panther the user originally installed. For this reason, I really with Repair Permissions would check the newer
Apple packages first rather than the older ones. Of course, if they did that, there wouldn't be a long list of changed files to give people that don't understand what permissions are the sense that they did some mystical voodoo magic which will make their computer run better.
In short, I could kind of understand if people wanted to run Repair Permissions after installing a third-party package by a vendor you don't trust. And in a setting like a lab, you probably do want to run Repair Permissions every once in a while just to make sure that some file or folder didn't inadvertently become writable by users that shouldn't have write access. And if you want to run Repair Permissions after installing an Apple software update, it probably won't hurt anything, but proclaiming that you must
do so is just plain ridiculous. And running Repair Permissions before
running a software update is completely
pointless, especially if you were going to run it after the update anyway. I guarantee you that there will be absolutely zero
difference to any
of your files whether you run Repair Permissions before the update or not if you were going to run it afterward. Guaranteed.
Why is this advice harmful, and why does it get my ire up so much when I hear people parroting it? Well, think about it. By telling newbies that they have to perform this voodoo ritual of running Repair Permissions twice
every software update, you've turned a nice, convenient feature into a confusing, time-consuming process. While Software Update is a quick, easy, and painless thing to do when you can just get it started and then go have a cup of coffee and let it finish whenever it's ready, if you have to mess with Repair Permissions it becomes a chore. This is going to breed a generation of users who just don't bother with Software Update because it's a pain in the ass. So you'll end up with unapplied security updates, machines still running 10.3.1, and if someone ever finds a really nasty security hole, all these users will be wide open. You'll also generate a lot of bad press about Apple ("Mac OS X is so retarded, you have to repair permissions every time you do a simple Software Update!"), as we all know the effect these rumors have, whether informed or no.
In summary, don't listen to the members of the cargo cult
of Repair Permissions. They don't understand what is really going on when they do this stuff, and they are out to waste your time.