Re: [COREUTILS 2/2] ls: Don't treat lack of acl support as an error

[Andreas Grünbacher]

2015-04-21 5:40 GMT+02:00 Pádraig Brady <address@hidden>:
> I dislike this change actually.
> Or more accurately, the gnulib change that changed the file_has_acl()
> interface, requiring this change.
>
> Previously in gnulib we mapped ENOTSUP to return 0 using:
> http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/acl-errno-valid.c
>
> Since we've now changed file_has_acl() to return -1 in this case,
> all gnulib users may now be printing erroneous errors etc.
>
> Is there any reason not to use the same gnulib acl_errno_valid() logic
> in the newly added "avoiding libacl" path?

Indeed, it was not a good idea to change file_has_acl() in a way that
will cause other users to silently fail. I dislike the calling convention
used, it's just bizarre, but let's leave it the way it is right now.

I have updated my repositories on github:

  https://github.com/andreas-gruenbacher/gnulib
  https://github.com/andreas-gruenbacher/coreutils

Any progress with the qset_acl and qcopy_acl rewrite on non-Linux platforms?

Thanks for your work and your review.

Andreas