First impressions of Snow Leopard 10.6.2

I installed 10.6.2 Combo Update a few hours ago and have been trying all my apps on it. It's quick and smooth. I haven't had as much as a burp out of this baby. Safari seems very peppy. Web sites come up very quickly.

Anyone having problems?

Installed it too; no problem so far. Upon permissions repair, the only thing showing up is:
Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified and will not be repaired.
I guess, it can be disregarded.

I got the same message. I believe it's one of those "throw aways" that are there for reasons I don't fully understand.

I had one minor glitch on one of our Macs but I honestly cannot say if it was the result of the update or merely a coincidence. Keynote presentations were not displaying correctly and some windows were outsized. The fix was to reset the display resolution to an odd size and then back to the correct size. But as I said, I cannot say definitively whether or not that was a result of the 10.6.2 update.

no problems here.

Thanks for the counsel oh great sages.

When my machine returns from Apple, I'll do the install.

Alas, two days ago, my HD started making the dreaded clicking sound. And, of course, all went wacko from there. As to the warranty, I was three weeks out of date. Not to worry says Apple, the replacement is free. And, the old 250 GB HD is being replaced with a 320 GB. I would say "woot", but I am about 45 years beyond that, so I'll just sing their (Apple) praises.

Originally Posted By: macnerd10

Installed it too; no problem so far. Upon permissions repair, the only thing showing up is:
Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified and will not be repaired.
I guess, it can be disregarded.

I got the same warning.

I recall getting something similar with 6.1 except that there were two of them. I had a clone of my drive so thought I'd risk trashing them and see what would happen on restart. Nada, so you may be right about disregarding the warning - although it'd be nice if terminology other than "Warning" could be used.

ryck

I'd be interested to see what the various 10.6.2 machines represented in this thread produce for output, in response to this Terminal command:

pkgutil -v --file-info /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

Anyone? â€” That will list any incarnations of ARDAgent installed previously and currently in the OS (at least as far as Disk Utility will be able to discern), indicating which package it came from, as well as its SHA-1 digest value.

Originally Posted By: Hal Itosis

Anyone?

Sure....although I have no idea what you said. Following is what I got with only My-Name or MyName substituted.

I don't know if it's relevant but, being a Terminal novice (Gads, what a poor choice of words), I decided to make a clone first and I noticed that Super Duper ran somewhat faster than it normally does.

ryck

My-Names-imac:~ MyName$ pkgutil -v --file-info /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
2009-11-15 15:23:37.769 pkgutil[485:903] PackageKit: *** Missing bundle identifier: /Library/Receipts/Flip4Mac QuickTime Components.pkg
2009-11-15 15:23:37.802 pkgutil[485:903] PackageKit: *** Missing bundle identifier: /Library/Receipts/Flip4Mac Web Plugins.pkg
volume: /
path: /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

pkgid: com.apple.pkg.Essentials
pkg-version: 10.6.0.1.1.1249291854
install-time: Tue Oct 13 13:24:46 2009
uid: 0 (root)
gid: 0 (wheel)
mode: 4755 (?rwsr-xr-x )

pkgid: com.apple.pkg.RemoteDesktopClient
pkg-version: 3.3.1
install-time: Mon Oct 19 22:22:40 2009
uid: 0 (root)
gid: 0 (wheel)
mode: 4755 (?rwsr-xr-x )
My-Names-imac:~ MyName$

Originally Posted By: Hal Itosis

Anyone? â€” That will list any incarnations of ARDAgent installed previously and currently in the OS (at least as far as Disk Utility will be able to discern), indicating which package it came from, as well as its SHA-1 digest value.

Here's mine with identifying info left out:

volume: /
path: /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

pkgid: com.apple.pkg.Essentials
pkg-version: 10.6.0.1.1.1249291854
install-time: Mon Aug 31 16:54:37 2009
uid: 0 (root)
gid: 0 (wheel)
mode: 4755 (?rwsr-xr-x )

Here's mine, omitting several unrelated " *** Missing bundle identifier ..." messages:

volume: /
path: /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

pkgid: com.apple.pkg.Essentials
pkg-version: 10.6.0.1.1.1249291854
install-time: Wed Sep 9 18:35:40 2009
uid: 0 (root)
gid: 0 (wheel)
mode: 4755 (?rwsr-xr-x )

pkgid: com.apple.pkg.Essentials
pkg-version: 10.4
install-time: Wed Feb 1 21:38:30 2006
uid: 0 (root)
gid: 0 (wheel)
mode: 4755 (?rwsr-xr-x )

pkgid: com.apple.pkg.RemoteDesktopClient
pkg-version: 3.3.1
install-time: Fri Aug 21 20:39:28 2009
uid: 0 (root)
gid: 0 (wheel)
mode: 4755 (?rwsr-xr-x )

I don't see any SHA-1 data in there, nor any mention of SHA-1 in man pkgutil. Changing "--file-info" to "--file-info-plist" gives me not output at all (beyond the "missing bundle identifier" messages).

...and mine:

volume: /
path: /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

pkgid: com.apple.pkg.Essentials
pkg-version: 10.6.0.1.1.1249291854
install-time: Sat Oct 31 21:16:01 2009
uid: 0 (root)
gid: 0 (wheel)
mode: 4755 (?rwsr-xr-x )

pkgid: com.apple.pkg.RemoteDesktopClient
pkg-version: 3.3.1
install-time: Mon Sep 28 07:34:01 2009
uid: 0 (root)
gid: 0 (wheel)
mode: 4755 (?rwsr-xr-x )

EDIT

Repairing permissions for â€œMacintosh HDâ€
Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified and will not be repaired.

Permissions repair complete

(edited to add results of Disk Utility Repair Permissions...)

Mine is like Ryck's:

2009-11-15 19:55:45.776 pkgutil[1477:903] PackageKit: *** Missing bundle identifier: /Library/Receipts/Flip4Mac QuickTime Components.pkg
2009-11-15 19:55:45.829 pkgutil[1477:903] PackageKit: *** Missing bundle identifier: /Library/Receipts/Flip4Mac Web Plugins.pkg
volume: /
path: /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

pkgid: com.apple.pkg.Essentials
pkg-version: 10.6.0.1.1.1249291854
install-time: Mon Aug 31 22:23:44 2009
uid: 0 (root)
gid: 0 (wheel)
mode: 4755 (?rwsr-xr-x )

pkgid: com.apple.pkg.RemoteDesktopClient
pkg-version: 3.3.1
install-time: Wed Sep 2 00:42:06 2009
uid: 0 (root)
gid: 0 (wheel)
mode: 4755 (?rwsr-xr-x )
myname-macbook-pro:~ myname$

Originally Posted By: ganbustein

Here's mine, omitting several unrelated " *** Missing bundle identifier ..." messages:

volume: /
path: /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

pkgid: com.apple.pkg.Essentials
pkg-version: 10.4
install-time: Wed Feb 1 21:38:30 2006
uid: 0 (root)
gid: 0 (wheel)
mode: 4755 (?rwsr-xr-x )

.

Oh no you didn't.

[also, if anyone *new* is going to jump in here... it helps to know whether or not permissions repair is "reporting" any Warning: SUID file verbiage.]

Originally Posted By: ganbustein

I don't see any SHA-1 data in there, nor any mention of SHA-1 in man pkgutil. Changing "--file-info" to "--file-info-plist" gives me not output at all (beyond the "missing bundle identifier" messages).

Well Sir, you're the one who introduced me to pkgutil... so this is all your fault.

As you well know, Leopard Lite (10.5) is loaded with that info. I'll post the last entry (of 9):

Code:

$ pkgutil -v --file-info /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
     volume: /
       path: System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent


       pkgid: com.apple.pkg.update.os.10.5.8.combo
 pkg-version: 1.0.1.1191932192
install-time: Thu Sep  3 12:18:26 2009
         uid: 0 (root)
         gid: 0 (wheel)
        mode: 104755 (-rwsr-xr-x )
        sha1: <e5af66d2 8074b92e a70f4154 339ece31 e905e64b>

But you're right... from the looks of things in posts above, the digest is gone. So how then does Snowy determine "has been modified" now... via size and modification date??? [nah, i bet the info is still in there... hidden somewhere... we probably just need to hold down the *option* key now to see it.

]

--

EDIT(s): FWIW, the man pkgutil page in 10.5 doesn't "mention" SHA-1 (or sha1) either... but that's not too surprising, really. It's not as if companies (especially Apple) are about to reveal to the world all their inside stuff. I'm almost surprised that there *is* a man page for it, and that the binary resides in such an accessible location (like /usr/sbin/pkgutil), for us all to play around with it so easily. [What does whereis lsregister get us? Nothing... try locate]. I'm not even sure to what extent pkgutil is intended for developers. (Is it?) It's my *assumption* that /Library/Receipts/db/a.receiptdb was intended as an Apple-only area. [although... a recent Growl update did find its way in there.]

@ macnerd10, MacManiac, ryck, and JoBoy...
Hey gang... Swell. Perfect. Thanks for all that.

Well, if that SHA-1 info is now hiding behind some option (or perhaps only available to DURP somehow?), or gone entirely... then my intended investigation is pretty much dead in the water.

Though... some info is still visible. I find this commonality to be a rather odd development:

Quote:

mode: 4755 (?rwsr-xr-x )

Here's what 10.5 tracked...

Quote:

mode: 104755 (-rwsr-xr-x )

...which is what one would expect. I don't want to go into details at this hour, but i see some serious corners being cut. And -- as evidenced here (as well as elsewhere) by continued glitchy updates w.r.t. DURP reporting stuff we can no longer [properly] guess precisely where/when the boo-boo might be happening -- it would seem that even the "corner-cutting" bandages aren't too effective at this juncture. [i.e., instead of fixing the problem at its source, the approach seems to be more one of either masking the symptoms, or simply having DURP do less checking.]

--

I guess we'll just have to ride this one out in the dark. [Anyone remember all those "special permissions" messages in 10.4 that lasted an eternity? Or how about when DURP reported permissions in *decimal* -- e.g., 33261?

Gracious, it's almost as if there's some technician setting up these little foibles deliberately... and then just sitting back at his house, laughing at the results.]

Anyway, i feel certain Good Sir Ganbustein knows way more about this stuff than i do. My main motivation [since before OSX 10.4 even] is: i would like to see Disk Utility and its comrades (Installer.app, Software Update.app, etc) all work together and perform as impeccably as possible. I'm afraid 10.6 will not fulfill that desire.

Oh well... when does 10.7 come out then? [or, perhaps i should just learn the joys of lowered expectations.]

FWIW, I went back and added in the DURP results on my earlier post....there were a bunch of minor permissions issues resolved on the first pass, and the SUID warning re: ARD was the only item that remained on the subsequent pass.

sorry I'm late, Hal. here's what I got on my 10.6.2 MacBook

Quote:

volume: /
path: /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

pkgid: com.apple.pkg.Essentials
pkg-version: 10.6.0.1.1.1249291854
install-time: Sat Aug 29 09:25:33 2009
uid: 0 (root)
gid: 0 (wheel)
mode: 4755 (?rwsr-xr-x )

pkgid: com.apple.pkg.RemoteDesktopClient
pkg-version: 3.3.1
install-time: Fri Aug 21 09:27:31 2009
uid: 0 (root)
gid: 0 (wheel)
mode: 4755 (?rwsr-xr-x )

and from permission repair:

Quote:

Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified and will not be repaired.

Originally Posted By: Hal Itosis

Oh no you didn't.

Oh yes I did!

Originally Posted By: Hal Itosis

Well Sir, you're the one who introduced me to pkgutil... so this is all your fault.

Sorry about that.

Originally Posted By: Hal Itosis

But you're right... from the looks of things in posts above, the digest is gone. So how then does Snowy determine "has been modified" now... via size and modification date??? [nah, i bet the info is still in there... hidden somewhere... we probably just need to hold down the *option* key now to see it.

]

You must have missed the memo about how the stepping stones got moved. You were probably still on vacation then. (That'll teach you. Step out of the room, and we'll keep right on playing without you.) Anyway, if you want to continue walking on water after you move to snow country, look for the stepping stones in /var/db/receipts.

Snow Leopard apparently got tired of people using Leopard, Tiger, or even Jaguar versions of Disk Utility to do permissions repair. The Snow Leopard installer guts /Library/Receipts/BSD.pkg (leaving only an empty folder) so that pre-Snow Leopard versions of Disk Utility think there's no OS on the disk. /Library/Receipts/db/a.receiptdb is no longer being updated.

Since you haven't taken the icy plunge yet, I list here one of those stepping stones:

defaults read /var/db/receipts/com.apple.pkg.Essentials

Code:

{
    InstallDate = "2009-09-09 18:35:40 -0700";
    InstallPrefixPath = "/";
    InstallProcessName = "Mac OS X Installer";
    PackageFileName = "Essentials.pkg";
    PackageGroups =     (
        "com.apple.snowleopard-repair-permissions.pkg-group",
        "com.apple.FindSystemFiles.pkg-group"
    );
    PackageIdentifier = "com.apple.pkg.Essentials";
    PackageVersion = "10.6.0.1.1.1249291854";
    PathACLs =     {
        Applications = "!#acl 1\\ngroup:ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000000C:everyone:12:deny:delete\\n";
        "Applications/Utilities" = "!#acl 1\\ngroup:ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000000C:everyone:12:deny:delete\\n";
        Library = "!#acl 1\\ngroup:ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000000C:everyone:12:deny:delete\\n";
        "System/Library/User Template/English.lproj/Desktop" = "!#acl 1\\ngroup:ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000000C:everyone:12:deny:delete\\n";
        "System/Library/User Template/English.lproj/Documents" = "!#acl 1\\ngroup:ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000000C:everyone:12:deny:delete\\n";
        "System/Library/User Template/English.lproj/Downloads" = "!#acl 1\\ngroup:ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000000C:everyone:12:deny:delete\\n";
        "System/Library/User Template/English.lproj/Library" = "!#acl 1\\ngroup:ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000000C:everyone:12:deny:delete\\n";
        "System/Library/User Template/English.lproj/Library/Application Support" = "!#acl 1\\ngroup:ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000000C:everyone:12:deny:delete\\n";
        .
        . (lots more like that, elided for brevity)
        .
    };
    PathSHA1Checksums =     {
        "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" = <cffc33a1 b351a828 36c2b44a cd7a6f00 033893c3>;
        "System/Library/Printers/IOMs/LPRIOM.plugin/Contents/MacOS/LPRIOMHelper" = <75bff4bc cf6663e2 b523c8cc ae8b101f 67764c69>;
        "usr/bin/login" = <4b5223b3 19d15a54 49ea0737 bbecfc03 23cc01eb>;
        "usr/lib/sa/sadc" = <ba93ea4d 55bed2ee 37a80fad f7ba2df3 942a805d>;
        "usr/libexec/authopen" = <6cba773c c0ab23fa 26616b2d 6df87d4d ec2e9339>;
        "usr/libexec/chkpasswd" = <0c49734a 4f6c23a1 b1337893 31ae4ca2 bd6d5809>;
        "usr/libexec/security_authtrampoline" = <fa8672d1 4ba075d0 736c73af cc0f4441 dbafec40>;
    };
}

Enjoy!

Just so you'll know: that's apparently the only checksum for ARDAgent, even though I'm now on 10.6.2:

find /var/db/receipts -name '*.plist' | while read x; do defaults read "${x%%.plist}" | grep ARDAgent && echo $VT_BOLD$x$VT_NORMAL; done
"System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" = <cffc33a1 b351a828 36c2b44a cd7a6f00 033893c3>;
/var/db/receipts/com.apple.pkg.Essentials.plist

In /var/db/receipts, next to each packagename.plist is the corresponding packagename.bom, which is presumably where the raw permissions can be found. There are no other files in the folder; that is, nothing like a.receiptsdb.

Originally Posted By: ganbustein

Anyway, if you want to continue walking on water after you move to snow country, look for the stepping stones in /var/db/receipts.

Ouch. Now that i see it in print, i recall that MicroMatTech3 did pass that information along in a (mid-September?) thread, but -- since i've haven't entered the Snowy landscape yet -- i totally forgot the fact. Sincere apologizes all around.

Originally Posted By: ganbustein

I list here one of those stepping stones:
defaults read /var/db/receipts/com.apple.pkg.Essentials
<snip>
"System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" = <cffc33a1 b351a828 36c2b44a cd7a6f00 033893c3>;
</snip>

Wow, thanks. [plists eh?... it all looks yummy.]

Originally Posted By: ganbustein

Just so you'll know: that's apparently the only checksum for ARDAgent, even though I'm now on 10.6.2:

find /var/db/receipts -name '*.plist' | while read x; do defaults read "${x%%.plist}" | grep ARDAgent && echo $VT_BOLD$x$VT_NORMAL; done
"System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" = <cffc33a1 b351a828 36c2b44a cd7a6f00 033893c3>;
/var/db/receipts/com.apple.pkg.Essentials.plist

In /var/db/receipts, next to each packagename.plist is the corresponding packagename.bom, which is presumably where the raw permissions can be found. There are no other files in the folder; that is, nothing like a.receiptsdb.

Okay cool. Hmm, so -- if we were to try and dig deeper into the "how/why does the DURP warning come about?" question -- the next step might be to at least have a look at what sort of checksums folks are sporting on that file now:

openssl sha1 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

Or perhaps you have some idea already [?]. My guess is (obvious i suppose) that some subsequent update (prolly 10.6.2) installed a tweaked version of ARDAgent, and (as with 10.5) it simply didn't put the latest digest value somewhere that DURP could "see" it. But why not?

It does seem that -- despite the relocated receipt info -- the exact same problem has followed along from 10.5 to 10.6 . . . so then it's probably something they have in common. [i think peeking into some of the postflight installer scripts might provide a clue perhaps. idunno, maybe.]

-+-

I imagine folks would also get a "valid on disk" reply to this as well:

codesign -vvv /System/Library/CoreServices/RemoteManagement/ARDAgent.app

I.e., everything is just fine... and everyone except DURP knows it.

Originally Posted By: Hal Itosis

Now that i see it in print, i recall that MicroMatTech3 did pass that information along in a (mid-September?) thread, but -- since i've haven't entered the Snowy landscape yet -- i totally forgot the fact.

I had forgotten too, actually, until you nudged me. I've given up on DURP as a (for the time being) lost cause. I don't think I've ever run it under Snow Leopard.

Originally Posted By: Hal Itosis

My guess is (obvious i suppose) that some subsequent update (prolly 10.6.2) installed a tweaked version of ARDAgent, and (as with 10.5) it simply didn't put the latest digest value somewhere that DURP could "see" it. But why not?

It does seem that -- despite the relocated receipt info -- the exact same problem has followed along from 10.5 to 10.6 . . . so then it's probably something they have in common.

And that's why I've given up on DURP. It's on my "just don't do that" list.

Some output you may find of interest:

VT_BOLD=$'\E[1m'
VT_NORMAL=$'\E[0m'
find /var/db/receipts -name '*.bom' | while read x; do lsbom "$x" | grep MacOS/ARDAgent && echo $VT_BOLD$x$VT_NORMAL; done
./System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent 104755 0/0 1676800 4158722535
/var/db/receipts/com.apple.pkg.Essentials.bom

codesign -vvv /System/Library/CoreServices/RemoteManagement/ARDAgent.app
/System/Library/CoreServices/RemoteManagement/ARDAgent.app: valid on disk
/System/Library/CoreServices/RemoteManagement/ARDAgent.app: satisfies its Designated Requirement

openssl sha1 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
SHA1(/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent)= e5af66d28074b92ea70f4154339ece31e905e64b

ls -lOe /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
-rwsr-xr-x 1 root wheel - 2528064 Aug 10 18:04 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

Notice that the modify date (Aug 10) predates the day I installed Snow Leopard (Sep 9).

Originally Posted By: ganbustein

find /var/db/receipts -name '*.bom' | while read x; do lsbom "$x" | grep MacOS/ARDAgent && echo $VT_BOLD$x$VT_NORMAL; done

DURN YOU!!!

... i was just this second typing up a post suggesting a similar lsbom/grep scrubbing...

echo; find /var/db/receipts -name '*.bom' |
while read x; do if lsbom -p MUGsf "$x" |
grep 'ARDAgent$'; then echo "$x"; echo; fi; done

Originally Posted By: Hal Itosis

DURN YOU!!!

... i was just this second typing up a post suggesting a similar lsbom/grep scrubbing...

echo; find /var/db/receipts -name '*.bom' |
while read x; do if lsbom -p MUGsf "$x" |
grep 'ARDAgent$'; then echo "$x"; echo; fi; done

Same output as what I posted, except for spelling out 0/0 as "root wheel" and omitting the 32-bit CRC checksum.

One more tidbit, FYI...

Originally Posted By: ganbustein

The Snow Leopard installer guts /Library/Receipts/BSD.pkg (leaving only an empty folder) so that pre-Snow Leopard versions of Disk Utility think there's no OS on the disk.

Hate to bust that theory, but i first noticed that BSD package was gutted sometime in 2008. Here is my (Leopard 10.5.8) rendition of that item:

$ ls -laR /Library/Receipts/BSD.pkg
-rw-r--r-- 1 root admin 0 Nov 29 2007 /Library/Receipts/BSD.pkg

It's an empty file!!!

[perhaps that was something Leopard did to distract Tiger?]

Originally Posted By: ganbustein

Same output as what I posted, except for spelling out 0/0 as "root wheel" and omitting the 32-bit CRC checksum.

>>> /Library/Receipts/db/a.receiptdb is no longer being updated.

Okay... but just for grins, please run it [lsbom|grep] on the old /Library/Receipts folder. If anything relevant [recent] pops up, post back. Other than that, mount the 10.6.2 dmg and poke through that package [with Pacifist i suppose, unless expanding the whole thing into /tmp sounds tempting]. A match to that e5af66d28074b92ea70f4154339ece31e905e64b digest must be somewhere.

OTHER THAN MY POST #5855 THAT IS

<e5af66d2 8074b92e a70f4154 339ece31 e905e64b>
See that? -- Your current "Snow Leopard" ARDAgent is identical to the one i have from 10.5.8 !!!

-- so what is that telling us?
-- do you guys have the right ARDAgent or not??
-- if so, how could Snowy *not* know that???

[if DURP can't get this stuff right, should we trust it for *anything*?]

Has anybody noticed whether "SnapBack" has been restored to Safari yet?

Thanks

Originally Posted By: artie505

Has anybody noticed whether "SnapBack" has been restored to Safari yet?

It's not there. I wrote to Apple at Mac OS X Feedback to complain (again). In case you didn't know, the ability to clear recent Google searches has been restored although I would like to see a way to clear selected searches. As of now, it's all or nothing.

Originally Posted By: Hal Itosis

Hate to bust that theory, but i first noticed that BSD package was gutted sometime in 2008. Here is my (Leopard 10.5.8) rendition of that item:

$ ls -laR /Library/Receipts/BSD.pkg
-rw-r--r-- 1 root admin 0 Nov 29 2007 /Library/Receipts/BSD.pkg

It's an empty file!!!

I don't know how you got that. On my 10.5.8 volume, I have:

ls -lOde /Volumes/Savanna/Library/Receipts/BSD.pkg
drwxrwxr-x 3 root admin - 102 Jun 14 2006 /Volumes/Savanna/Library/Receipts/BSD.pkg

du -sh /Volumes/Savanna/Library/Receipts/BSD.pkg
3.2M /Volumes/Savanna/Library/Receipts/BSD.pkg

On my 10.6.2 volume I have:
ls -lOde /Library/Receipts/BSD.pkg
-rw-r--r-- 1 root admin - 0 Sep 9 18:33 /Library/Receipts/BSD.pkg

So you're right about it leaving an empty file rather than an empty folder. The date (Sep 9) is the day I installed 10.6.0.

I first noticed this while digging into a complaint from a fellow MUG member that her Jaguar DURP was refusing to even look at her Snow Leopard system, despite never having balked at repairing permissions on her Tiger and Leopard systems. I read her the riot act about not using old repair utilities on new systems and the converse in DURP's case (and didn't hide my feelings on DURP in general), but I was curious to know why Jaguar's DURP, which obviously never checked versions before, was suddenly doing it now.

BSD.pkg was the one thing that the Snow Leopard installer changed that Jaguar's DURP would have looked at.

Originally Posted By: ganbustein

I don't know how you got that.

Via a clean install perhaps. [i.e., freshly erased the HD just moments prior to installing 10.5.0]

Originally Posted By: artie505

Has anybody noticed whether "SnapBack" has been restored to Safari yet?

Not missed, since simply clicking and holding on the back arrow is much better.
[i.e., we can pick a specific level to jump back to, not just the "top of the site".]

ls -laR /Library/Receipts/BSD.pkg
-rw-r--r-- 1 root admin 0 May 3 2008 /Library/Receipts/BSD.pkg

Clean install here, too. (Now @ 10.5.7.)

Originally Posted By: Hal Itosis

Originally Posted By: artie505

Has anybody noticed whether "SnapBack" has been restored to Safari yet?

Not missed, since simply clicking and holding on the back arrow is much better.
[i.e., we can pick a specific level to jump back to, not just the "top of the site".]

Still, you have to admire the optimism revealed in the use of the word "yet."

I expect SnapBack to return hard on the heels of Sherlock...right after the OS 9.5 update.

Quote:

Has anybody noticed whether "SnapBack" has been restored to Safari yet?

> Not missed, since simply clicking and holding on the back arrow is much better.

Hmmm... I don't know about much better, but I'll play with it; thanks for the thought.

>[i.e., we can pick a specific level to jump back to, not just the "top of the site".]

Don't forget that we can change our SnapBack level by hitting command-option-K at any point along the trail, and that would be nicely augmented by "click and hold."

> Still, you have to admire the optimism revealed in the use of the word "yet."

What the hey!

FireWire 400 "snapped back," and at what, I imagine, is far greater cost than restoring "SnapBack" would entail.

> I expect SnapBack to return hard on the heels of Sherlock...right after the OS 9.5 update.

...and immediately preceding the unveiling of the "FTM Mac FAQ Forum" to which I (not to mention others) have also devoted a considerable amount of optimism!

Originally Posted By: ganbustein

Just so you'll know: that's apparently the only checksum for ARDAgent, even though I'm now on 10.6.2:

find /var/db/receipts -name '*.plist' | while read x; do defaults read "${x%%.plist}" | grep ARDAgent && echo $VT_BOLD$x$VT_NORMAL; done
"System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" = <cffc33a1 b351a828 36c2b44a cd7a6f00 033893c3>;
/var/db/receipts/com.apple.pkg.Essentials.plist

In /var/db/receipts, next to each packagename.plist is the corresponding packagename.bom, which is presumably where the raw permissions can be found. There are no other files in the folder; that is, nothing like a.receiptsdb.

Hey gang, i need some help with Snowy... and ganbustein appears to be on another extended leave (last post was before Thanksgiving 2009, both here and macosxhints). I'm still holding off on 10.6 until it comes pre-installed on my new MacBook Pro (due to be announced tomorrow?), so could any Snow Leopard user kindly run these three commands for me please:

Code:

ls -Orbitlake /Volumes


find /var/db/receipts -name '*.bom' |
while read x; do if lsbom -p MUGsf "$x" |
grep '/Volumes$'; then echo "$x"; echo; fi; done


find /var/db/receipts -name '*.plist' |
while read x; do defaults read "${x%%.plist}" | 
grep '/Volumes$' && echo "$x"; done

I'm investigating an odd ACL on the /Volumes folder (which has appeared in only a few macosxhints forums so far), and i'm trying to determine first of all where it's coming from (or at least where it's *not*).

TIA.

edit: note that those commands just read info... no changes happen to your disk.

ls -Orbitlake /Volumes

total 4
2 drwxrwxr-x 14 jonathanmchuzi staff - 544 Mar 18 2009 Time Machine HD
2 drwxr-xr-x 37 jonathanmchuzi staff - 1326 Jan 28 17:14 Storage HD
2 drwxrwxr-t 31 root admin - 1122 Feb 10 08:12 Backup HD
2 drwxrwxr-t 30 root admin - 1088 Feb 21 17:48 ..
7092757 lrwxr-xr-x 1 root admin - 1 Feb 22 16:25 SnowLeopard HD -> /
6041943 drwxrwxrwt@ 6 root admin hidden 204 Feb 22 16:29 .
0: group:everyone deny add_file,add_subdirectory,directory_inherit,only_inherit

find /var/db/receipts -name '*.bom' |
while read x; do if lsbom -p MUGsf "$x" |
grep '/Volumes$'; then echo "$x"; echo; fi; done

drwxrwxrwt root admin ./Volumes
/var/db/receipts/com.apple.pkg.BaseSystem.bom

find /var/db/receipts -name '*.plist' |
while read x; do defaults read "${x%%.plist}" |
grep '/Volumes$' && echo "$x"; done

Nothing happened with this one, Hal.

ls -Orbitlake /Volumes

total 4
2 drwxrwxr-t 32 root admin - 1156 Nov 10 06:15 ..
4943721 lrwxr-xr-x 1 root admin - 1 Feb 22 14:38 Macintosh HD -> /
4304933 drwxrwxrwt@ 3 root admin hidden 102 Feb 22 14:39 .
0: group:everyone deny add_file,add_subdirectory,directory_inherit,only_inherit

find /var/db/receipts -name '*.bom' |
while read x; do if lsbom -p MUGsf "$x" |
grep '/Volumes$'; then echo "$x"; echo; fi; done

drwxrwxrwt root admin ./Volumes
/var/db/receipts/com.apple.pkg.BaseSystem.bom

find /var/db/receipts -name '*.plist' |
while read x; do defaults read "${x%%.plist}" |
grep '/Volumes$' && echo "$x"; done

...yields a return to the command line without any additional information....

Outstanding!

Originally Posted By: jchuzi

ls -Orbitlake /Volumes
6041943 drwxrwxrwt@ 6 root admin hidden 204 Feb 22 16:29 .
0: group:everyone deny add_file,add_subdirectory,directory_inherit,only_inherit

What a strange ACL! I need to figure out if Apple put that there, or if some 3rd-party program does.

--> Have you got some specialized backup software related to some disk storage you bought... or are you just doing basic Time Machine plus SuperDuper? <--

Originally Posted By: jchuzi

find /var/db/receipts -name '*.bom' |
while read x; do if lsbom -p MUGsf "$x" |
grep '/Volumes$'; then echo "$x"; echo; fi; done

drwxrwxrwt root admin ./Volumes
/var/db/receipts/com.apple.pkg.BaseSystem.bom

Okay cool... now i need to figure out where Apple keeps the ACL info.
For 10.5 we could do this:

pkgutil -v --file-info /Volumes

...but i don't think 10.6 is updating things where pkgutil can read it anymore.

Originally Posted By: jchuzi

find /var/db/receipts -name '*.plist' |
while read x; do defaults read "${x%%.plist}" |
grep '/Volumes$' && echo "$x"; done

Nothing happened with this one, Hal.

Hmm. Interesting [not what i'd expect.]

Thanks Jon.

Originally Posted By: MacManiac

ls -Orbitlake /Volumes

total 4
2 drwxrwxr-t 32 root admin - 1156 Nov 10 06:15 ..
4943721 lrwxr-xr-x 1 root admin - 1 Feb 22 14:38 Macintosh HD -> /
4304933 drwxrwxrwt@ 3 root admin hidden 102 Feb 22 14:39 .
0: group:everyone deny add_file,add_subdirectory,directory_inherit,only_inherit

That clinches it... i guess Apple does put that there then.

Still wish i knew in which plist or db they store that info... so it could be verified.

Seems like a really odd thing to do... put an ACL with **inheritance** there that makes folders unwritable (except to root). Strange.

You don't have any fancy backup software program that came with a NAS, or something of that nature do you? [then again, any installer could have put that there. If it was Apple, it sure seems unnecessary (or some sort of mistake).]

Thanks Lee.

Originally Posted By: Hal Itosis

Have you got some specialized backup software related to some disk storage you bought... or are you just doing basic Time Machine plus SuperDuper?

I'm just using TM and SD, nothing else.

Cheers, okay thanks.

How about anti-virus software then? idunno... it's such an odd ACL (especially the inheritance part). It does look like something Intego might do. I know... i'm going down to the Apple Store tomorrow and run some Terminal commands on one of the demo Macs there. Those oughta be virginal enough.

If it's an Apple ACL, i'd sure like someone to explain its purpose.

Interesting question about AV software. I have Intego VB 4 installed (it's a leftover from 10.5) but it doesn't work in 10.6. I have neither uninstalled it nor upgraded to VB 6, just left it alone, probably out of sheer laziness.

not sure if you still want this, but here it is:

ls -Orbitlake /Volumes

total 4
2 drwxrwxr-t 34 root admin - 1224 Nov 9 22:06 ..
18101545 lrwxr-xr-x 1 root admin - 1 Feb 17 17:36 Macintosh HD -> /
16112489 drwxrwxrwt@ 3 root admin hidden 102 Feb 17 18:41 .
0: group:everyone deny add_file,add_subdirectory,directory_inherit,only_inherit

find /var/db/receipts -name '*.bom' |
> while read x; do if lsbom -p MUGsf "$x" |
> grep '/Volumes$'; then echo "$x"; echo; fi; done

drwxrwxrwt root admin ./Volumes
/var/db/receipts/com.apple.pkg.BaseSystem.bom

find /var/db/receipts -name '*.plist' |
> while read x; do defaults read "${x%%.plist}" |
> grep '/Volumes$' && echo "$x"; done

nothing.

Originally Posted By: roger

not sure if you still want this, but here it is:

ls -Orbitlake /Volumes
total 4
2 drwxrwxr-t 34 root admin - 1224 Nov 9 22:06 ..
18101545 lrwxr-xr-x 1 root admin - 1 Feb 17 17:36 Macintosh HD -> /
16112489 drwxrwxrwt@ 3 root admin hidden 102 Feb 17 18:41 .
0: group:everyone deny add_file,add_subdirectory,directory_inherit,only_inherit

What in blazes does that ACL do?!?!

Seems like it might lock out regular users from accessing *folders* inside /Volumes, perhaps while a mount is in progress (transitioning from an empty directory to an alias), in which case the folder usually gets deleted once the alias is established. <sigh> idunno... it just has an aura of being a little too slick. It may prevent regular users from writing to failed mounts... but backup programs (which sometimes mistakenly write to real folders inside /Volumes) will often run with root privileges anyway, so...

--

Thanks Roger.