[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:
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