DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 52SA0oI03957310
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 52SA0oI03957310
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=MaxPfpXx
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 50926382E2A6
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1743156049;
	bh=ilKIam3pSkEkOj5n3d1n2S9V6NS9RnJbbE55M+vdzto=;
	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=MaxPfpXxsiV44zvB9++l8G42PXd8P/r/WGTleEUNI/DKmi9ptN38fIi4HxSpxGMzh
	uKX39lB1IMyDzUn04FMdIghjXQ6cnvQenWaC0q5JYAAjHi+TGCeGswmLy3S2a1NPda
	+oKLJ1RX8LMyPEXbrIK26Vnmdeu9k7Ltq6PjqdPs=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 29234382E285
Date:	Fri, 28 Mar 2025 10:59:36 +0100
To:	Bruno Haible <bruno AT clisp DOT org>
Subject:	Re: symbolic link curiousity in 3.6.0
Message-ID:	<Z-ZzCHWkcsvBApLK@calimero.vinschen.de>
Mail-Followup-To:	Bruno Haible <bruno AT clisp DOT org>, cygwin AT cygwin DOT com
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>
MIME-Version:	1.0
In-Reply-To:	<Z-UtUsdcnKf4cf-F@calimero.vinschen.de>
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
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>, cygwin AT cygwin DOT com
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>

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


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

- Raw text -