symbolic link curiousity in 3.6.0

[Paul Eggert]

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.