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
