10.6.8
|
|
OP
Joined: Aug 2009
|
Just updated using the Combo, which weighed in over 1GB. All is well. ...Now, Lion is next.
MacStudio M1max - 14.4.1, 64 GB Ram, 4TB SSD; Studio Display; iPhone 13mini; Watch 9; iPadPro (M2) 11" WiFi
|
|
Re: 10.6.8
|
Joined: Aug 2009
Likes: 7
|
Joined: Aug 2009
Likes: 7 |
I updated via Software Update (275 MB) and all is well.
Jon
macOS 11.7.10, iMac Retina 5K 27-inch, late 2014, 3.5 GHz Intel Core i5, 1 TB fusion drive, 16 GB RAM, Epson SureColor P600, Photoshop CC, Lightroom CC, MS Office 365
|
|
Re: 10.6.8
|
Joined: Aug 2009
Likes: 14
|
Joined: Aug 2009
Likes: 14 |
Same as Jon....used Software Update....all's well in this neck of the woods.
ryck
ryck
"What Were Once Vices Are Now Habits" The Doobie Brothers
iMac (Retina 5K, 27", 2020), 3.8 GHz 8 Core Intel Core i7, 8GB RAM, 2667 MHz DDR4 OS Sonoma 14.4.1 Canon Pixma TR 8520 Printer Epson Perfection V500 Photo Scanner c/w VueScan software TM on 1TB LaCie USB-C
|
|
Re: 10.6.8
|
|
Joined: Aug 2009
|
likewise, and seems pretty snappy.
|
|
Re: 10.6.8
|
|
Joined: Aug 2009
|
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?
MicroMat Inc Makers of TechTool
|
|
Re: 10.6.8
|
Joined: Aug 2009
Likes: 15
|
Joined: Aug 2009
Likes: 15 |
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" )
The new Great Equalizer is the SEND button.
In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
|
|
Re: 10.6.8
|
|
Joined: Aug 2009
|
artie505,
Thanks for reminding me why I usually wait for the combo updater. (18 minutes to complete “Repair Permissions†after using Software Update.)
MicroMat Inc Makers of TechTool
|
|
Re: 10.6.8
|
|
Joined: Sep 2009
|
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? 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.
|
|
Re: 10.6.8
|
|
Joined: Aug 2009
|
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-- .
MicroMat Inc Makers of TechTool
|
|
Re: 10.6.8
|
|
Joined: Sep 2009
|
Yuck. Well, anything involving a link we can probably just ignore. I see two types above... 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.]
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.
Last edited by Hal Itosis; 06/25/11 06:37 AM.
|
|
|
|