At 12:27 AM +0100 3/15/07, Giuliano Gavazzi wrote:
I have to change my earlier statement about 10.4.9 having solved
rsync problems with ACLs and resource forks.
It only works locally. Across machines, using ssh, ACLs are
corrupted in some way*.
Unfortunately I had to wait the official release before I could
install on two machines and so the problem escaped me.
* in the example I run the UID in the transferred ACL cannot be
resolved. The error message at ls -e is: Unable to translate
qualifier on ACL.
That should very arguably be the expected behavior. (The msg
"Unable to translate qualifier on ACL." would seem to confirm this.)
ACLs on Alice's system are different (a whole domain in scope) over
Bob's system and any ACLs there, or to where they are copied. Bob's
scope is different. The ACL no longer applies because it's out of
scope.
A more interesting behavior would be if you copy it back; does it
still work as you then might also expect?
that is indeed what I had tried next, and it consistently copies back
as the original.
As for examining the ACL, it's simply a HFS+ Attributes File entry,
expressed in Tiger as an EA with the com.apple.system.Security
attribute, which unless you're in the com.apple.system.Security
domain is private or not exposed to the rest of the system. (You
are free, of course, to read it explicitly yourself. We don't live
in a day where dd does work. Yet. So you /can/ read it. :wink: )
You could try filing a radar on this, but I suspect that the
behavior's correct.
done, and I agree with you, although I there is some basis in saying
that users should be identified by name alone, as it is done at the
ordinary unix permission level.
But I consider the ACL issue with rsync to have significant
philosophical complications no matter how you slice it. Yet these
are the most understandable and sane of rysnc's issues in Tiger.
I this this issue stems from:
uuid_to_name in file_cmds-116.9/ls/print.c
and in turn from mbr_uuid_to_id (see man page).
Also, nicl . -read /users|groups/whatever will show (for some users|
groups) something called generateduid, which might have to do with
the above.
I did another test: I used an ACL that referred to a group (admin for
instance). It transferred fine. In this case the generateduid is the
same on both (presumably all) systems. I also created a new group
(this one without generateduid) and it also worked.
So this is not an issue as long as:
1) one restores on the original system (that might not be possible,
but one should also backup all the relevant system files)
or
2) one uses only group based ACLs (which is a good idea).
Unfortunately there seem to be no way to specify a group acl when
there is also a user by the same name. If somebody knows how to work
around that please let me know.
Giuliano
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
