symbolic link curiousity in 3.6.0

[Pádraig Brady]

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