ACL found but not expected
The general reason ACLs do get reported is that: Disk Utility apparently tracks a few of them it (supposedly) knows about... so it tells the user —for purposes of information only —when it find any that it (supposedly) didn't know about.
The general reason ACLs never get fixed is that: we users may have put that ACL there (or changed it) intentionally... and DU doesn't want to undo some intention we may have had. [ACLs can be configured by us to either allow or deny access in a myriad of ways... so they are handy for both sharing and/or securing.]
So -- if all that is still not understood -- then fine. Ignore both me and Disk Utility.
What i can't ignore is that those three folders you mentioned...
ACL found but not expected on "Applications/Utilities".
ACL found but not expected on "Applications".
ACL found but not expected on "Library"....those are items on which Disk Utility **should** expect an ACL to be.
So what's the problem? Has the ACL been
modified, and is it now different than Apple's default? I doubt it (but we could find out quick enough):
ls -led /Applications{,/Utilities} /Library
I suspect though that nothing is out of the ordinary, which means that the bug started in 10.5.0 still lives on in 10.6.3 (because Disk Utility is somehow referencing incorrect info after a software update).
Anyway, bottom line: yes ignore it (probably), but
just know that it's buggy behavior and don't grow to think of it as normal. [OTOH, if a user (or some script)
does deliberately alter those ACLs, then
yes --
that's when DU
should issue such a report.]
