2015-04-21 5:40 GMT+02:00 Pádraig Brady <p...@draigbrady.com>: > 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
