Hi Bruno, On Mar 29 15:02, Bruno Haible via Cygwin wrote: > 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.
Actually, after having some time to think more about this, I disagree. First of all, Cygwin provides the acl_extended_file() function and it's doing the POSIXly correct thing. Second, your code mixes Windows and POSIX points of view as to what constitutes a extended vs. trivial ACL. However, Cygwin is *deliberatly* using the POSIX point of view and *deliberatly* providing the user with the POSIX POV. Third, the filtering of Administrator and SYSTEM GROUP entries is already performed by Cygwin itself. Your code is duplicating what Cygwin does and only adds a test for the Users group, which is kinda questionable. If we decide to change the ACL functions to ignore, for example, the Domain Users group to evaluate an ACL for triviality, this would not be reflected by ls(1), which is IMHO not a good thing. And if we did that accidentally, due to a bug, it might even be covered by ls(1), which is even worse. If you create a native Windows version, it's ok to check the ACL inside gnulib, because there's no such thing as a Windows function returning a triviality indicator. But Cygwin is *not* Windows, it's POSIX on Windows. And it has a matching function. Forth, by not trusting Cygwin to do the right thing and adding a lot of unnecessary code for each single ACL, you slow down ls(1) even more on Cygwin, which already gets a beating for being slow. I think it would be nice if you would accept how we do things and why we do things. Gnulib supports the target system and fills the gaps where the target system is lacking, and I'm very grateful for gnulib. But I'm not talking about bugs here, rather about what we think is right or wrong. And in this case, I think we're doing the right thing, and gnulib "knows better" and is trampling over it. Therefore I would like to ask you to reconsider and to remove the Cygwin-special code and let Cygwin decide by itself, what a trivial vs. non-trivial ACL is by using the POSIXy functions Cygwin provides. Just use acl_extended_file(), please. Thanks, 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
