symbolic link curiousity in 3.6.0

[Bruno Haible]

Corinna Vinschen wrote:
> > Regarding what acl_extended_file() does, there is the man page by
> > Andreas Grünbacher:
> > https://www.kernel.org/doc/man-pages/online/pages/man3/acl_extended_file.3.html
> > Gnulib is not the only user of acl_extended_file(); therefore I would
> > suggest that Cygwin should follow that man page — regardless of Gnulib.
> 
> It already does!  The acl_extended_file() change for directories we just
> talked about will actually be a deviation from Andreas' man page.

OK, then Cygwin's acl_extended_file should not change.

> > An ACL implementation that shows a '+' sign on 99.9% of the files is
> > not useful. A user can't practically run 'getfacl' on all files and
> > understand the result. In other words, ACLs need to be the special case,
> > not the common case.
> 
> Yeah, that's a good point.  If the user is beaten with a stick with
> a '+' sign written on it, it's basically no help.

Glad to have an agreement here. Then, gnulib won't change: it will not
use Cygwin's acl_extended_file() function and instead use the function
acl_access_nontrivial(), defined in Gnulib.

> But your question was specificially about files created in the above
> dir:
> 
> - Files created by a Cygwin process inside that dir will have only the
>   usual three ACL entries constituting standard POSIX permission bits,
>   combined with their umask, i.e.:
> 
>   $ cd /tmp/glo1FkFx/tmpdir0
>   $ umask
>   22
>   $ touch foo
>   $ getfacl foo
>   # file: foo
>   # owner: corinna
>   # group: vinschen
>   user::rw-
>   group::r--
>   other::r--
> 
> - Files created by non-Cygwin processes inside that dir will have by
>   default(*) only the usual three ACL entries constituting standard
>   POSIX permission bits, but there's no umask handling in the non-Cygwin
>   process, i.e.
> 
>   $ cd /tmp/glo1FkFx/tmpdir0
>   $ cmd
>   C:\cygwin64\tmp\glQatIoG\tmpdir0>echo foo > bar
>   C:\cygwin64\tmp\glQatIoG\tmpdir0>exit
>   $ getfacl bar
>   # file: bar
>   # owner: corinna
>   # group: vinschen
>   user::rwx
>   group::r-x
>   other::r-x
> 
>   (*) Most Windows processes rely entirely on the permissions in
>   the ACLs and the Windows ACL inheritance rules.
> 
> Does that answer your question?

Thanks for explaining. This matches my earlier experiments on Cygwin;
see these comments in the acl_access_nontrivial function:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/acl-internal.c;h=6c50feacbb811da92da9a68d544132d87ad8dbf3;hb=HEAD#l80

So, in summary, I too see the action item (regarding the behaviour
of 'ls' on symlinks) more on the coreutils side.

Bruno