DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52SBO4Z23986661
Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 52SBO4Z23986661
Authentication-Results: delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=CpC7vXYY
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3FC313842FFD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1743161043;
	bh=ahHuGnz2FbQaAGspAtDhmOCJpEvBAImiz4lMTMOabew=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=CpC7vXYYGkVNmy60/vObvcYv/P1HFhpPo/67F62KfeWUIjOQB9dVttyGbwn9EkjwK
	 jT+uo1cQ1H2DxmBNpSVg6G0CNIiPx5dF0h7xwMy1xcTzr21BvDjS3Ds1d26SBjZrML
	 kaGBVdW+xaxvWoOrn0gaKuWrJRlIymhr/WVl6uU8=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 37D6138438AB
Date: Fri, 28 Mar 2025 12:21:56 +0100
To: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Subject: Re: symbolic link curiousity in 3.6.0
Message-ID: <Z-aGVCUo0N1VSl5s@calimero.vinschen.de>
Mail-Followup-To: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>,
 Bruno Haible <bruno AT clisp DOT org>
References: <Pine DOT BSF DOT 4 DOT 63 DOT 2503250218240 DOT 74063 AT m0 DOT truegem DOT net>
 <Z-J95wRzwkj8RLeT AT calimero DOT vinschen DOT de>
 <8758454b-bd9f-427b-9cc7-854ffd9b9596 AT maxrnd DOT com>
 <Z-UtUsdcnKf4cf-F AT calimero DOT vinschen DOT de>
 <Z-ZzCHWkcsvBApLK AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <Z-ZzCHWkcsvBApLK@calimero.vinschen.de>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>,
        Bruno Haible <bruno AT clisp DOT org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

On Mar 28 10:59, Corinna Vinschen via Cygwin wrote:
> [Adding Bruno Haible]
> 
> Hi Bruno,
> 
> can you please take a look?  To reiterate, with coreutils 9.6:
> 
>   $ ln -s foo bar
>   $ ls -l bar
>   ls: bar: Not supported
>   lrwxrwxrwx 1 corinna vinschen 3 Mar 27 10:20 bar -> foo
> 
> The introducing commit in coreutils is apparently commit
> b58e321c8d5dd ("ls: suppress "Permission denied" errors on NFS")
> 
> The reason this works as expected on Linux but not on Cygwin is that the
> underlying gnulib function file_has_aclinfo() differs between Linux and
> Cygwin.  On Cygwin, it's basically just a call to acl_get_file() since
> Cygwin has the POSIX.1e functions but none of the extensions of Linux
> or FreeBSD/NetBSD.
> 
> As a result, when calling file_has_aclinfo("bar",...), the symlink
> "bar" is always followed and file_has_aclinfo() returns with errno
> set to ENOENT.
> 
> See below for the rest of the story.
> 
> Two questions:
> 
> - Would you place the problem inside gnulib:file_has_aclinfo() or
>   coreutils:gobble_file()?
> 
>   Personally I think this is a coreutils problem rather than a
>   gnulib problem in that it fails to take ENOENT on symlinks into
>   account.
> 
> - Would it make sense to implement the FreeBSD/NetBSD functions
>   acl_get_fd_np() and acl_get_link_np() in Cygwin?  Theoretically
>   this should fix the problem without having to fix coreutils,
>   but I think coreutils really should take systems into account
>   which only have the documented POSIX.1e functions.
> 
> What do you think?

Ok, there's something fishy going on.

Cygwin has acl_extended_file/acl_extended_file_nofollow.

And after configure, gnulib's config.h contains this:

  #define USE_ACL 1
  #define HAVE_ACL_GET_FILE 1
  #define HAVE_ACL_EXTENDED_FILE 1

But for some reason I still have to figure out the coreutils 9.6 build
doesn't use acl_extended_file/acl_extended_file_nofollow, but
acl_get_file.

Hmm...


Corinna


> 
> 
> Thanks,
> Corinna
> 
> On Mar 27 11:49, Corinna Vinschen via Cygwin wrote:
> > [...]
> > Ok, this looks like a coreutils 9.6 problem.
> > 
> > What happens is that 9.6 `ls -l' tries to fetch the ACL of "bar".
> > However, "bar" is a symlink, and the underlying acl_get_file() function
> > resolves symlinks.  What it does is, it tries to open("bar") for reading
> > the ACL.  This is resolved into "foo", which doesn't exist.  So the open
> > call returns ENOENT, and this is returned to the calling ls(1) function
> > file_has_aclinfo().
> > 
> > Two frames up is the function gobble_file().  This function encounters a
> > return value of -1 from the called function file_has_aclinfo_cache()
> > with errno set to ENOENT.  Next is a funny expression:
> > 
> >   bool cannot_access_acl = n < 0 && errno == EACCES;
> > 
> > So cannot_access_acl is not set, because errno is not EACCES.
> > 
> > 9 lines later, we have this expression:
> > 
> >   if (format == long_format && n < 0 && !cannot_access_acl)
> >     error (0, ai.u.err, "%s", quotef (full_name));
> > 
> > And this is what prints the "Not supported" error to stdout, because
> > ai.u.err is preloaded earlier with ENOTSUPP.
> > 
> > So the entire reason for the message is an (IMHO wrong) expectation in
> > terms of calling acl_get_file() on a symlink.
> > 
> > I'd be surprised if that doesn't occur on Linux as well, unless it's
> > wrong that Cygwin's acl_get_file() follows symlinks.
> > 
> > However, I checked this scenario codewise against libacl, which is the
> > library providing acl_get_file() on Linux.
> > 
> > ACLs on Linux are stored in extended attributes, and consequentially
> > libacl's acl_get_file() calls getxattr(filename, ...) to fetch the ACL.
> > Note, it calls getxattr, NOT lgetxattr, so it follows symlinks just as
> > Cygwin's acl_get_file().
> > 
> > What surprises me is that you say it doesn't occur prior to the -327
> > test release.  It occurs even back to 3.5.5 for me.  The error occuring
> > here shouldn't depend on the Cygwin version.  "foo" doesn't exist and
> > the open() behaviour of acl_get_file() has never changed for symlinks.
> > 
> > 
> > Corinna
> > 
> > -- 
> > 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
> 
> -- 
> 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

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