On 3/31/25 12:26, Corinna Vinschen wrote:
ls(1) always potentially shows a past state anyway.
Sure, but traditionally (and I'm talking about 7th edition Unix) a
single output line of 'ls' corresponded to a state obtained atomically
from the file system. I realize we can't always do that nowad
On Mar 31 12:12, Paul Eggert via Cygwin wrote:
> On 3/31/25 11:27, Pádraig Brady wrote:
> > The file could be deleted at any time.
> > We're just suppressing errors in the edge case it's deleted
>
> More generally, though, the file could be renamed and another put in its
> place, which means that
On 3/31/25 11:27, Pádraig Brady wrote:
The file could be deleted at any time.
We're just suppressing errors in the edge case it's deleted
More generally, though, the file could be renamed and another put in its
place, which means that an attacker could cause 'ls' to generate a line
that does
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
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 fo
