On 2025-03-30 05:50, Corinna Vinschen wrote:
The definition of O_PATH requires an additional
#include <fcntl.h>
Thanks, I added that and installed the patch into Gnulib.
However, assuming not only Cygwin is affected, shouldn't the patch
rather use O_PATH if it's available, O_RDONLY if not?
I hope only Cygwin is affected. The only other platforms mentioned in
the code that might also be affected are IRIX and Tru64, neither of
which is supported these days. I don't think the code would work on a
Linux kernel, as acl_get_fd doesn't work with O_PATH fds as I recall;
however this code should never be compiled with Linux so it should be OK.
If we run into the problem on a non-Cygwin platform we can complicate
the patch along the lines that you suggest. Any such complication would
involve more than merely using O_RDONLY, though, as the code should work
even on unreadable files.
-# if HAVE_ACL_GET_LINK_NP /* FreeBSD, NetBSD >= 10 */
+# if HAVE_ACL_GET_LINK_NP /* FreeBSD, NetBSD >= 10, Cygwin >= 2.5 */
Changing the comment is wrong, IMHO. We're adding a local version of
HAVE_ACL_GET_LINK_NP specificially because Cygwin (or, FWIW, any system
only providing the POSIX.1e draft 17 function) does not provide
acl_get_link_np, isn't it?
As far as I know only Cygwin has the problem.
For Cygwin, I will add this function nevertheless, but it will only be
available in some upcoming version, either 3.6.1 or 3.7.0.
It's funny that so many operating systems are adding an
"acl_get_link_np" function to mean the same thing, when "_np" means "not
portable". This API is badly designed but I guess we're stuck with it.
In terms of coreutils, I think either ls(1) gobble_file() or
file_has_aclinfo_cache() should still handle ENOENT from
file_has_aclinfo() and not print any error message.
I'm not so sure about this, but one issue at a time.
