symbolic link curiousity in 3.6.0

[Pádraig Brady]

On 31/03/2025 17:32, Paul Eggert wrote:
> On 2025-03-30 07:26, Pádraig Brady wrote:
>> On 30/03/2025 13:50, Corinna Vinschen wrote:
>>> 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.  After all, due to
>>> the preconditions for building acl_get_link_np, we can't be sure
>>> acl_get_link_np has really been built into file-has-acl.c, and the
>>> problem persists.
>>
>> I tend to agree. I'll apply this later:
>>
>>
>> commit 88385a0d6d56197d3c180432c8a4bca07241e90b (HEAD -> master)
>> Author: Pádraig Brady <P@draigBrady.com>
>> Date:   Sun Mar 30 15:16:54 2025 +0100
>>
>>       ls: suppress ENOENT errors when reading ACL info
>>
>>       * src/ls.c (gobble_file): Indicating unknown ACL info with '?'
>>       suffices for the edge case of a file being removed while reading,
>>       or older cygwin when reading through dangling symlinks.
>>       Reported by Corinna Vinschen.
> 
> Not sure this is a good idea, as a file being removed while getting its
> attributes indicates a serious issue that's worth bringing to the user's
> attention more directly.

I don't think this is a serious issue.
The file could be deleted at any time.
We're just suppressing errors in the edge case it's deleted
in the small window between the stat() and the acl_get_file().
We of course don't guarantee a file is present after we list it,
so we shouldn't jump through hoops for this edge case I think.

> How about if we instead use O_PATH on the file first, and then use fstat
> etc. on the result? That should fix the
> file-removed-while-getting-attributes situation, at least on platforms
> with /proc/self/fd (which I assume includes Cygnus). I realize that
> flistxattr etc. don't work on fds opened via O_PATH (why? this seems
> silly, but it's not my bailiwick) but /proc/self/fd works around that
> problem.

cheers,
Pádraig