symbolic link curiousity in 3.6.0

Mon Mar 31 16:32:14 GMT 2025

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.
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.