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
