bug#17669: Fwd: Re: Solaris acl woes

[Ben Walton]

On Jun 3, 2014 11:22 AM, "Pádraig Brady" <address@hidden> wrote:
>
> On 06/03/2014 07:51 AM, Ben Walton wrote:
> > On Jun 2, 2014 6:46 PM, "Paul Eggert" <address@hidden> wrote:
> >>
> >> [Forwarding this to Bug#17669 as bug-coreutils seems to have misfiled
it
> > under 17664; closing 17664.]
> >>
> >> -------- Original Message --------
> >> Subject:        Re: Solaris acl woes
> >> Date:   Mon, 02 Jun 2014 06:56:03 -0700
> >> From:   Paul Eggert <address@hidden>
> >> Organization:   UCLA Computer Science Department
> >> To:     Ben Walton <address@hidden>, address@hidden,
> > address@hidden
> >>
> >>
> >>
> >> Ben Walton wrote:
> >>
> >>> The lib/file-has-acl.c:acl_ace_nontrivial code that returns 1 is:
> >>
> >>
> >> Why is it returning 1, exactly?  What are the value of access_masks[0,
> >> 1] and how do they compare to the masks, and what bits are set that
> >> shouldn't be if we want the ACLs to be trivial?
> >
> > I didn't get back to this yesterday but will tonight.
> >
> > What do you think about the fact that the Solaris tools seem to exhibit
the
> > same behavior?
>
> I'd probably adjust the tests to first:
>
> getfacl test.acl | setfacl -f - test.acl || skip_ "system is unable to
copy ACLs"
>

Not a bad idea, but those tools have different names on different systems
and possibly different calling conventions.

If this is a preferred approach, at the very least, a presence check for
the binary needs to wrap the precondition.

Thanks
-Ben

> thanks,
> Pádraig
>