An open community 
of Macintosh users,
for Macintosh users.

FineTunedMac Dashboard widget now available! Download Here

Previous Thread
Next Thread
Print Thread
10.6.8
#16272 06/24/11 05:26 PM
Joined: Aug 2009
pbGuy Offline OP
OP Offline

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
pbGuy #16273 06/24/11 05:31 PM
Joined: Aug 2009
Likes: 7
Offline

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
pbGuy #16275 06/24/11 07:39 PM
Joined: Aug 2009
Likes: 14
Offline

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 Ventura 13.6.3
Canon Pixma TR 8520 Printer
Epson Perfection V500 Photo Scanner c/w VueScan software
TM on 1TB LaCie USB-C
Re: 10.6.8
ryck #16276 06/24/11 07:49 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
likewise, and seems pretty snappy.


MacBook 2.4 Ghz · 4 Gb ram · 10.7.5
stuff I'm interested in
iPhone 4s 7.0.2
Re: 10.6.8
roger #16280 06/24/11 09:07 PM
Joined: Aug 2009
Offline

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
MicroMatTech3 #16282 06/24/11 09:31 PM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Originally Posted By: MicroMatTech3
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" smile )


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
artie505 #16286 06/24/11 10:01 PM
Joined: Aug 2009
Offline

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
MicroMatTech3 #16289 06/24/11 10:13 PM
Joined: Sep 2009
Offline

Joined: Sep 2009
Originally Posted By: MicroMatTech3
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
Hal Itosis #16298 06/25/11 01:16 AM
Joined: Aug 2009
Offline

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
MicroMatTech3 #16301 06/25/11 06:08 AM
Joined: Sep 2009
Offline

Joined: Sep 2009
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.

Last edited by Hal Itosis; 06/25/11 06:37 AM.

Moderated by  alternaut, dkmarsh, joemikeb 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.4
(Release build 20200307)
Responsive Width:

PHP: 7.4.33 Page Time: 0.019s Queries: 35 (0.014s) Memory: 0.6220 MB (Peak: 0.7174 MB) Data Comp: Zlib Server Time: 2024-03-29 04:47:36 UTC
Valid HTML 5 and Valid CSS