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 -- 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
