[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andreas Grünbacher
Subject: Re: [COREUTILS 2/2] ls: Don't treat lack of acl support as an error
Date: Tue, 28 Apr 2015 13:48:13 +0200

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:


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

Thanks for your work and your review.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]