sysfs: always reopen directory before readdir

[haoqixu]

As POSIX states, 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.

So there is no guarantee that files added after opendir() will be visible in readdir(). We need to reopendir() to get the new state of the directory before readdir().

Btrfs was modified to track the last index number in opendir() and make readdir() never process beyond that index number (torvalds/linux@9b378f6). This change was introduced in Linux 6.4.12 (see https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.12). I think this change is the reason of the test failures in #2335.

I noticed that there is a similar commit in tmpfs (torvalds/linux@64a7ce7).

I can reproduce the testing failures on both btrfs and tmpfs filesystems on archlinux with 6.12.7 kernel

The behavior is not a bug, because the POSIX specification explicitly allows it. The PR sets reopenDir to true in newOsFile to always reopen directory before readdir.

Fixes #2335

For more information, here are some references:

• IterableDir does not iterate over all contents created after opening (Linux BTRFS) ziglang/zig#17095
• https://lore.kernel.org/linux-btrfs/[email protected]/T/#m6203070d4311563313f940741d22b768ac7e07c9
• https://pubs.opengroup.org/onlinepubs/007904875/functions/readdir.html

[james-lawrence]

could this also have been the cause of bad file errors I see infrequently?

[evacchi]

if this is the right behavior, probably worth adding a test to make sure that we won't change it in the future :)

[ncruces]

if this is the right behavior, probably worth adding a test to make sure that we won't change it in the future :)

I think the tests in #1087 already do this. I have some nits regarding the comment, but I'll address them myself later.