DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52SEVfaR4084691
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B17D8382E2B5
To: Corinna Vinschen <corinna-cygwin@cygwin.com>
Cc: bug-gnulib@gnu.org, cygwin@cygwin.com
Subject: Re: symbolic link curiousity in 3.6.0
Date: Fri, 28 Mar 2025 15:30:55 +0100
Message-ID: <11037686.3WhfQktd6Z@nimes>
Organization: GNU
In-Reply-To: <Z-aP1jhjXTUVvP-E@calimero.vinschen.de>
References: <Pine.BSF.4.63.2503250218240.74063@m0.truegem.net>
 <Z-aGVCUo0N1VSl5s@calimero.vinschen.de>
 <Z-aP1jhjXTUVvP-E@calimero.vinschen.de>
MIME-Version: 1.0
Precedence: list
From: Bruno Haible via Cygwin <cygwin@cygwin.com>
Reply-To: Bruno Haible <bruno@clisp.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

[CCing bug-gnulib]

Corinna Vinschen wrote in
<https://sourceware.org/pipermail/cygwin/2025-March/257751.html>:
> 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