GNU bug report logs - #20310
[COREUTILS 0/2] Improved acl handling

Previous Next

Full log

Message #16 received at 20310 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Grünbacher <andreas.gruenbacher <at> gmail.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 20310 <at> debbugs.gnu.org, bug-gnulib <at> gnu.org
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 <P <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.