Re: [regression] getdents() does not list entries created after opening the directory

[Christian Heusel <christian@heusel.eu>]

[-- Attachment #1: Type: text/plain, Size: 2509 bytes --]

On 24/10/01 02:49PM, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 01.10.24 14:18, Matthew Wilcox wrote:
> > On Tue, Oct 01, 2024 at 01:29:09PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> >>> 	DIR* dir = opendir("/tmp/dirent-problems-test-dir");
> >>>
> >>> 	fd = creat("/tmp/dirent-problems-test-dir/after", 0644);
> > 
> > "If a file is removed from or added to the directory after the most
> > recent call to opendir() or rewinddir(), whether a subsequent call to
> > readdir() returns an entry for that file is unspecified."
> > 
> > https://pubs.opengroup.org/onlinepubs/007904975/functions/readdir.html
> > 
> > That said, if there's an easy fix here, it'd be a nice improvement to
> > QoI to do it, but the test-case as written is incorrect.
> 
> Many thx Willy!
> 
> Which leads to a question:
> 
> Krzysztof, how did you find the problem? Was there a practical use case
> (some software or workload) with this behavior that broke and made your
> write that test-case? Or is that a test-program older and part of your
> CI tests or something like that?

The above message and the mentioned patch reminded me of an [old
issue][0] that is bothering us in the Arch Linux Infrastructure Team
which makes files vanish if modified during an rsync transaction (which
breaks our mirror infrastructure because it makes the package sync
databases [go missing][1]).

The issue was previously discussed with the BTRFS developers after they
implemented a [similar patch][2] (atleast judging from the title of
both) for their filesystem who also pointed to the standards compliance
after we have complained.

The workload and the issue with it (and how the new behaviour breaks
rsync for our usecase) was [nicely explained][3] by one of the BTRFS
developers.

So going back to the initial question: There could be a practical
usecase this causes a regression for, atleast if the patch has the same
implications as the BTRFS patch has. While we will have to sort out our
issue separately with the BTRFS folks I thought I'd still leave this
information in this thread.

> Ciao, Thorsten

Cheers,
Chris

[0]: https://lore.kernel.org/linux-btrfs/00ed09b9-d60c-4605-b3b6-f4e79bf92fca@foutras.com/
[1]: https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/585
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9b378f6ad48c
[3]: https://lore.kernel.org/linux-btrfs/ZP8AWKMVYOY0mAwq@debian0.Home/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]