On 28/03/2025 14:30, Bruno Haible via Gnulib discussion list wrote:
[CCing bug-gnulib]
Corinna Vinschen wrote in
<https://sourceware.org/pipermail/cygwin/2025-March/257751.html>:
Responding to previous messages in the above thread,
I think the triggering commit in coreutils 9.6 was:
https://github.com/coreutils/coreutils/commit/4ce432ad8
This displays ai->u.err on any issue getting acls etc.
However in the non USE_LINUX_XATTR case in file_has_aclinfo() in gnulib
we only initialize ai->u.err=ENOTSUP, but never set it otherwise.
So that means in coreutils we shouldn't be inspecting u.err at all,
and just printing errno like:
diff --git a/src/ls.c b/src/ls.c
index 244484439..46ec42037 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -3549,7 +3549,7 @@ gobble_file (char const *name, enum filetype type, ino_t
inode,
any_has_acl |= f->acl_type != ACL_T_NONE;
if (format == long_format && n < 0 && !cannot_access_acl)
- error (0, ai.u.err, "%s", quotef (full_name));
+ error (0, errno, "%s", quotef (full_name));
else
{
/* When requesting security context information, don't make
Note the coreutils code seemed to always output all errors from file_has_acl(),
so I'm presuming on earlier versions of coreutils we did output an ENOENT
error for the dangling symlink on cygwin?
That may be avoided with the adjustments discussed below.
I found the problem, it's in a gnulib header. See below.
...
Gnulib's acl-internal.h contains this:
/* Linux-specific */
/* Cygwin >= 2.5 implements this function, but it returns 1 for all
directories, thus is unusable. */
# if !defined HAVE_ACL_EXTENDED_FILE || defined __CYGWIN__
# undef HAVE_ACL_EXTENDED_FILE
# define HAVE_ACL_EXTENDED_FILE false
# define acl_extended_file(name) (-1)
# endif
This is simply not true. Cygwin's acl_extended_file only returns
1 on dirs, if they actually contain more than the 3 default entries
to emulate POSIX access. I just tried it and it works exactly
as required.
Can this be fixed, please?
If I comment out that part:
/* || defined __CYGWIN__ */
I get three test failures
FAIL: test-file-has-acl.sh
==========================
file_has_acl("tmpdir0") returned yes, expected no
FAIL test-file-has-acl.sh (exit status: 1)
FAIL: test-file-has-acl-1.sh
============================
file_has_acl("tmpdir0") returned yes, expected no
FAIL test-file-has-acl-1.sh (exit status: 1)
FAIL: test-file-has-acl-2.sh
============================
file_has_acl("tmpdir0") returned yes, expected no
FAIL test-file-has-acl-2.sh (exit status: 1)
from a testdir created with
$ ./gnulib-tool --create-testdir --dir=../testdir1 --single-configure acl
acl-permissions file-has-acl copy-file
This is reproducible with both Cygwin 2.9 and 3.6.0.
So, from my point of view, the situation is still the same as when
I introduced this workaround, in
https://lists.gnu.org/archive/html/bug-gnulib/2018-09/msg00089.html
Therefore, I see two possible ways forward:
a) The Cygwin function acl_extended_file gets modified so that it
is actually usable by Gnulib (i.e. does not cause test failures),
or
b) Investigate how to deal with the "Not supported" error in coreutils.
(Maybe silence and ignore this error?)
Bruno
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
