Just updated using the Combo, which weighed in over 1GB. All is well. ...Now, Lion is next.

I updated via Software Update (275 MB) and all is well.

Same as Jon....used Software Update....all's well in this neck of the woods.

ryck

likewise, and seems pretty snappy.

I repaired permissions after using Software Update, and found 7,366 needed repair, almost all of them in Airport Utility. Has anyone else had this odd result?

I d/l'ed and installed the Combo, and DU repaired only the old, familiar Java stuff. (1 min 23 secs to complete "Repair Permissions" )

artie505,

Thanks for reminding me why I usually wait for the combo updater. (18 minutes to complete “Repair Permissions” after using Software Update.)

The thing about repairing perms is: what exactly was "fixed" (i.e., what changes were supposedly needed), and... did those changes actually stick? (i.e., does a 2nd run-through show all is "clean"?)

Anyway, until Apple fixes the DURP bug, we simply can't trust it 100%. Last time i check, it's still SNAFU.

Hal,

Good point about permissions changes that stick. Here is what a rerun of Repair Permissions produced a few mintues ago:


Repairing permissions for “Macintosh HD”
Permissions differ on "System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar", should be lrwxr-xr-x , they are lrw-r--r-- .
Repaired "System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar".
User differs on "System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib", should be 0, user is 95.
Repaired "System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib".
User differs on "System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries", should be 0, user is 95.
Repaired "System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries".
Permissions differ on "System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/cacerts", should be lrwxr-xr-x , they are lrw-r--r-- .
Repaired "System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/cacerts".
Permissions differ on "System/Library/Java/Support/Deploy.bundle/Contents/Resources/Java/deploy.jar", should be lrwxr-xr-x , they are lrw-r--r-- .
Repaired "System/Library/Java/Support/Deploy.bundle/Contents/Resources/Java/deploy.jar".
Permissions differ on "System/Library/Java/Support/Deploy.bundle/Contents/Resources/JavaPluginCocoa.bundle/Contents/Resources/Java/deploy.jar", should be lrwxr-xr-x , they are lrw-r--r-- .
Repaired "System/Library/Java/Support/Deploy.bundle/Contents/Resources/JavaPluginCocoa.bundle/Contents/Resources/Java/deploy.jar".
Permissions differ on "System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/jconsole.jar", should be -rw-r--r-- , they are lrwxr-xr-x .
Repaired "System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/jconsole.jar".
User differs on "System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib", should be 95, user is 0.
Repaired "System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib".
User differs on "System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Libraries", should be 95, user is 0.
Repaired "System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Libraries".
Permissions differ on "System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/Deploy.bundle/Contents/Home/lib/security/cacerts", should be -rw-r--r-- , they are lrwxr-xr-x .
Repaired "System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/Deploy.bundle/Contents/Home/lib/security/cacerts".
Permissions differ on "System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/Deploy.bundle/Contents/Resources/Java/deploy.jar", should be -rw-r--r-- , they are lrwxr-xr-x .
Repaired "System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/Deploy.bundle/Contents/Resources/Java/deploy.jar".
Permissions differ on "System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/Deploy.bundle/Contents/Resources/Java/libdeploy.jnilib", should be -rwxr-xr-x , they are lrwxr-xr-x .
Repaired "System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/Deploy.bundle/Contents/Resources/Java/libdeploy.jnilib".
Permissions differ on "System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Resources/JavaPluginCocoa.bundle/Contents/Resources/Java/deploy.jar", should be -rw-r--r-- , they are lrwxr-xr-x .
Repaired "System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Resources/JavaPluginCocoa.bundle/Contents/Resources/Java/deploy.jar".
Permissions differ on "System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Resources/JavaPluginCocoa.bundle/Contents/Resources/Java/libdeploy.jnilib", should be -rwxr-xr-x , they are lrwxr-xr-x .
Repaired "System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Resources/JavaPluginCocoa.bundle/Contents/Resources/Java/libdeploy.jnilib".
Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified and will not be repaired.

Permissions repair complete

The only references to Java in the original Repair Permissions log:

Repaired "System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Resources/JavaPluginCocoa.bundle/Contents/Resources/Java/deploy.jar".
Permissions differ on "System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Resources/JavaPluginCocoa.bundle/Contents/Resources/Java/libdeploy.jnilib", should be -rwxr-xr-x , they are lrwxr-xr-x .
Repaired "System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Resources/JavaPluginCocoa.bundle/Contents/Resources/Java/libdeploy.jnilib".


Here is a typical entry for both group ownership and read, write, and execute permissions from the original Disk Utility repair permissions log. There are thousands of similar ones covering every language, as well as other files in the Airport Utility application package:

Group differs on "Applications/Utilities/AirPort Utility.app/Contents/Resources/Japanese.lproj/AirPortUtilityHelp/pgs/ap2047.html", should be 0, group is 80.
Permissions differ on "Applications/Utilities/AirPort Utility.app/Contents/Resources/Japanese.lproj/AirPortUtilityHelp/pgs/ap2047.html", should be -rw-r--r-- , they are -rw-rw-r-- .

Yuck.

Well, anything involving a link we can probably just ignore. I see two types above...

1. Quote:

   should be lrwxr-xr-x , they are lrw-r--r--
   
   Even if DURP is "right" (and i wouldn't bet on it), it doesn't matter there... because both items are links in that line... and perms on links are almost totally irrelevant (especially the execute bits it seems to want). A link's purpose is simply to transport us to the target. [i.e., it's only the perms on the target that really matter.]
   
   
   
2. Quote:

   should be -rw-r--r-- , they are lrwxr-xr-x
   
   That's the classic DURP burp right there: should be a file, but found a link. Well good luck... because there is no (simple) "command" which can transform a link into a file. One would need to remove the link and then copy some file in. [i.e., requires a change of file type (structure), not a 'permissions' change.] And behind all that noise is that DURP is simply referencing outdated information... thus it just doesn't realize that Apple recently redesigned the layout, by replacing the file with a link.

So... ignoring every item involving a link, you have five left:

• two: should be 0, user is 95
• two: should be 95, user is 0
  and
• one: Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified and will not be repaired.

That SUID one (which bugs me no end) is another DURP boo-boo. [or so we HOPE... because the day that hackers discover they can safely modify that file because Mac users typically ignore any warning about it, well... then we'll wake up i guess.] Anyway, that one tells us explicitly "will not be repaired"... so we can expect it to persist, until some update cleans up DURP's database. (there's more to say about how poorly suid items are mishandled, but i'll skip it this time).

The remaining four with 95 and 0 mixed up... idunno. They look new to me, but right now i'm not up to the hassle of checking them manually. [uid 95 is "_update_sharing" for whatever that's worth.]

With DURP's batting average these days, my assumption is: if DURP can't fix it then it must not need fixing in the first place. I haven't repaired perms in a few months, so maybe i'll just check and see what kind of "report" my MBP produces this weekend sometime.