DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52RB4Zrm3466473
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 52RB4Zrm3466473
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=LYl4lzL5
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5975A382E2A4
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1743073473;
	bh=qIncVTa5I5D0jTgdrlgDO6pLWAWuOcrpzKw8hwS9CFM=;
	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=LYl4lzL5Zt453VRIlD6HvKcLgbWrjgnibCbQnm325WxxJePFgR8c4oPwG2eirXbpM
	 dBMGvLQ84U9fHnnGoZTEJU9I/GyyxeTJwLm7gde2Bi2jIj6i27vVMEMGnjYvgSfzoF
	 nYFS3DG46nBXVm35zwaKP3FWhc1XACmX8dYSPRNI=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8486A382E285
Date: Thu, 27 Mar 2025 11:49:54 +0100
To: cygwin AT cygwin DOT com
Subject: Re: symbolic link curiousity in 3.6.0
Message-ID: <Z-UtUsdcnKf4cf-F@calimero.vinschen.de>
Mail-Followup-To: 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>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8758454b-bd9f-427b-9cc7-854ffd9b9596@maxrnd.com>
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>
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 25 15:12, Mark Geisert via Cygwin wrote:
> > 
> > Your ls output shows an at-sign after the name "bar".  You're
> > probably using an alias for ls including the -F option.  Can you
> > paste your alias here?
> 
> alias ls='ls -AF --color -bv -T 0'
> 
> The oddity occurs even if I use /bin/ls without options.
> 
> > Are you using a specific setting of the CYGWIN env var including
> > a symlink type?
> 
> The CYGWIN env var is empty.
> 
> > Can you try intermediate test release between 327 and -1?
> 
> The oldest test release available via setup is 422 and the oddity occurs
> there too.

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