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
