Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Looks good. >> You're welcome to commit regardless of the acl_trivial >> issue mentioned below. > > Thanks, applied with a tweak (attached below) that should fix a probable > breakage on IRIX in the original proposal. > >> Once you've investigated Solaris ACLs you might want to adjust that >> comment. I seem to recall seeing trivial ones with 4 or 5 entries. >> ... >> Have you considered using acl_trivial (also used in file-has-acl.c) >> or a replacement that encapsulates this test? > > Haven't thought about it yet. Is it the syntactic or semantic triviality > of the ACL which matters? (Example: If the file has the mode rwx------,
The goal in at least one place was to determine whether it was necessary to copy the ACL. Since naively testing n_entries is not effective with ZFS, using acl_trivial seems like the only sensible approach; it does the right thing, when it is available. That it misses the corner case mentioned in that bug report isn't a big deal for me. > owner = 101, and an additional ACL "user:150:---", the ACL is semantically > trivial: the additional ACL has no effect, since user 150 cannot access the IMHO, it is not cp's (or copy_file's) job to determine semantic triviality. It must copy any ACL that is not syntactically trivial. > file anyway. But it's not syntactically trivial: 'ls' or getfacl displays it, > and after the mode is changed to rwxrwx--- the additional ACL becomes > effective.) > > Also, I'm not sure whether it's worth to use a function whose only known > implementation (in Solaris) is buggy: > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6664043
