summaryrefslogtreecommitdiffstats
path: root/tests/bfs/color_escapes.out
diff options
context:
space:
mode:
authorTavian Barnes <tavianator@tavianator.com>2023-11-15 09:45:49 -0500
committerTavian Barnes <tavianator@tavianator.com>2023-11-15 09:54:18 -0500
commitfb4760db85c552b0f538f7af2ad40fa631c20540 (patch)
treee72288d2effb4079c2a63a68ff52cd2d1ac25afe /tests/bfs/color_escapes.out
parent8b312eb6553235c36f5483d4e46c5034dcc03ce2 (diff)
downloadbfs-fb4760db85c552b0f538f7af2ad40fa631c20540.tar.xz
tests: Fix a possible infinite loop
The POSIX spec for readdir() [1] says: > 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. which implies that a loop of readdir()/unlink()/creat() may continue to return new files unendingly. This was even observed on a Linux 6.6 tmpfs mount [2]. It's not clear whether find(1) is also permitted to loop endlessly in this case, but in case it is, let's avoid the whole problem by limiting the -exec to happen at most once. [1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.html [2]: https://lore.kernel.org/linux-fsdevel/20231113180616.2831430-1-tavianator@tavianator.com/
Diffstat (limited to 'tests/bfs/color_escapes.out')
0 files changed, 0 insertions, 0 deletions