DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52SIcEva416828
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 885BB3857BA5
Message-ID: <fc150eed-055f-466b-b419-acae4993af79@SystematicSW.ab.ca>
Date: Fri, 28 Mar 2025 12:37:41 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: symbolic link curiousity in 3.6.0
Content-Language: en-CA
To: cygwin@cygwin.com
References: <Pine.BSF.4.63.2503250218240.74063@m0.truegem.net>
 <Z-aGVCUo0N1VSl5s@calimero.vinschen.de>
 <Z-aP1jhjXTUVvP-E@calimero.vinschen.de> <11037686.3WhfQktd6Z@nimes>
Autocrypt: addr=Brian.Inglis@SystematicSW.ab.ca; keydata=
 xjMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePbN
 LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT7ClgQTFggA
 PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW
 AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO
 WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDM44BF6KcfMSCisGAQQBl1UB
 BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAfCfgQYFggAJhYhBMM5
 /lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF
 IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5
 RSyTY8X+AQ==
Organization: Systematic Software
In-Reply-To: <11037686.3WhfQktd6Z@nimes>
Precedence: list
From: Brian Inglis via Cygwin <cygwin@cygwin.com>
Reply-To: cygwin@cygwin.com
Cc: Brian Inglis <Brian.Inglis@SystematicSW.ab.ca>,
        Gnulib bugs <bug-gnulib@gnu.org>, Bruno Haible <bruno@clisp.org>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>
Content-Transfer-Encoding: 8bit

On 2025-03-28 08:30, Bruno Haible via Cygwin wrote:
> [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)

Expectations are incorrect: all NTFS files under Cygwin have ACLs and 
directories have ACLS and DACLs, and probably also NFS files and directories, 
unless you can access a FAT or other filesystem; but not on my local, nor 
probably our CI, whether GH or Appveyor?

Some package tests are skipped because they can not find suitable files or 
directories: for example, accessible but not owned by the build owner IIRC.
Perhaps these should also be such cases
If any test does any ftw, it should test all the cases required, as ftw seems to 
crawl all over our filesystems, taking ages, possibly because symlinks are maybe 
not checked for everywhere, or cygdrive is mapped to /mnt a la Linux?

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

Or could translate "readlink/at" ENOENT to EACCESS, although POSIX says EACCESS 
means "Search permission is denied for a component of the path prefix of path" 
or "The access mode of the open file description associated with fd is not 
O_SEARCH and the permissions of the directory underlying fd do not permit 
directory searches."?

I already maintain a bunch of Cygwin coreutils patches: one more will just delay 
starting to build a while longer, while I work around the latest releases 
changes! ;^>

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

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