> > > 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.
Let me summarize these arguments in a comment:
2025-03-30 Bruno Haible <br...@clisp.org>
file-has-acl: Update comments regarding Cygwin.
* lib/acl-internal.h (HAVE_ACL_EXTENDED_FILE, acl_extended_file): Add
more comments.
diff --git a/lib/acl-internal.h b/lib/acl-internal.h
index b32a1cdafd..cb969e9797 100644
--- a/lib/acl-internal.h
+++ b/lib/acl-internal.h
@@ -118,8 +118,13 @@ rpl_acl_set_fd (int fd, acl_t acl)
# endif
/* Linux-specific */
-/* Cygwin >= 2.5 implements this function, but it returns 1 for all
- directories, thus is unusable. */
+/* Cygwin >= 2.5 implements acl_extended_file(), but it returns 1 for nearly
all
+ directories â for reasons explained in
+ <https://sourceware.org/pipermail/cygwin/2025-March/257762.html> â, thus
is
+ unusable. For the user, 'ls' should not print a '+' sign, indicating the
+ presence of an ACL, for 99,9% of the files; this would not be useful.
+ Therefore, on Cygwin, we ignore the acl_extended_file function and instead
+ use our own acl_access_nontrivial function. */
# if !defined HAVE_ACL_EXTENDED_FILE || defined __CYGWIN__
# undef HAVE_ACL_EXTENDED_FILE
# define HAVE_ACL_EXTENDED_FILE false
