symbolic link curiousity in 3.6.0

Fri Mar 28 09:59:36 GMT 2025

[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