bug#81444: chown, chmod, chgrp, chcon, ls: --recursive walk does not ignore ENOENT errors

On 23/07/2026 10:06, Paul Holzinger wrote:
> Hi Padraig,
> 
> On 22/07/2026 21:51, Pádraig Brady wrote:
>> On 20/07/2026 18:12, Paul Holzinger via GNU coreutils Bug Reports wrote:
>>> Hi,
>>>
>>> I noticed that when chown'ing a directory tree recursively with many
>>> files sometimes chown will exit 1 and report ENOENT errors. This happens
>>> when looping over the directory results from readdir() and in a parallel
>>> another process removes a file before the code then calls stat(),
>>> chmod() or whatever syscalls the command has to do for the given
>>> filename.
>>>
>>> Since such race is expected the coreutils should not treat this as error
>>> and just ignore them instead. That way a parallel removal of a file will
>>> not make the commands return exit code 1 and thus possibility break
>>> scripts. Of course this should only apply to files or directories under
>>> the main path given as input, i.e. chmod -R dest should still fail with
>>> ENOENT when dest does not exists.
>>>
>>> Below is a reproducer for the commands, might needs to run a few times
>>> until it triggers the race condition, I am not sure if there are more
>>> commands in coreutils which are affected by this.
>> Thanks for the repro, it works well.
>>
>> I agree, these commands shouldn't warn or fail for files
>> being added, replaced, removed in the tree being traversed.
>> I also notice that du is affected.
>>
>> The attached should hopefully address this issue.
> 
> Thanks for the patch, I tested it with the reproducer and it works well.
> 
> I also agree with the other comments, just ignoring ENOENT is good
> enough for me.
Thanks for checking.

Pushed with only ENOENT considered.

Merking this as done.

thanks,
Padraig