When used on mergerfs mount points the mc-4.8.26-r1 produces weird output where it lists every item as if it was two separated items. Downgrading to mc-4.8.25-r1 fixes the issue. Reproduced on all my systems. Steps to reproduce: - Merge app-misc/mc-4.8.26-r1 - merge any version of mergerfs - run: mkdir -p foo/foo1 bar/bar1 baz - run: mergerfs $(pwd)/foo:$(pwd)/bar baz - run: 'mc' and enter the baz directory - enjoy double listing of foo1 and bar1 - downgrade to app-misc/mc-4.8.25-r1 and check the baz mount point, no double listing.
Yeah, happens here as well. I think it's a bug in mergerfs probaby related to lseek() handlink: 2835843 openat(AT_FDCWD, "/tmp/bug/baz", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 6</tmp/bug/baz> 2835843 newfstatat(6</tmp/bug/baz>, "", {st_mode=S_IFDIR|0755, st_size=60, ...}, AT_EMPTY_PATH) = 0 2835843 getdents64(6</tmp/bug/baz>, 0x56185ff38a60 /* 4 entries */, 32768) = 96 2835843 lseek(6</tmp/bug/baz>, 0, SEEK_SET) = 0 2835843 getdents64(6</tmp/bug/baz>, 0x56185ff38a60 /* 8 entries */, 32768) = 192 2835843 newfstatat(AT_FDCWD, "/tmp/bug/baz/foo1", {st_mode=S_IFDIR|0755, st_size=40, ...}, AT_SYMLINK_NOFOLLOW) = 0 2835843 newfstatat(AT_FDCWD, "/tmp/bug/baz/bar1", {st_mode=S_IFDIR|0755, st_size=40, ...}, AT_SYMLINK_NOFOLLOW) = 0 2835843 newfstatat(AT_FDCWD, "/tmp/bug/baz/foo1", {st_mode=S_IFDIR|0755, st_size=40, ...}, AT_SYMLINK_NOFOLLOW) = 0 2835843 newfstatat(AT_FDCWD, "/tmp/bug/baz/bar1", {st_mode=S_IFDIR|0755, st_size=40, ...}, AT_SYMLINK_NOFOLLOW) = 0 2835843 getdents64(6</tmp/bug/baz>, 0x56185ff38a60 /* 0 entries */, 32768) = 0 2835843 close(6</tmp/bug/baz>) = 0 Note how getdents64() returns 8 entries as a single syscall (after I guess new mc happens to use rewinddir(). Here is a reproducer in C: $ cat a.c #include <sys/types.h> #include <dirent.h> #include <stdio.h> int main() { DIR * d; struct dirent * e; printf("first read:\n"); d = opendir("baz"); while (e = readdir(d)) { printf("e: %s\n", e->d_name); } printf("second read:\n"); rewinddir(d); while (e = readdir(d)) { printf("e: %s\n", e->d_name); } closedir(d); } $ gcc a.c -o a && ./a first read: e: . e: .. e: foo1 e: bar1 second read: e: . e: .. e: foo1 e: bar1 e: . e: .. e: foo1 e: bar1
mc probably changed behaviour in https://github.com/MidnightCommander/mc/commit/27de03754fb790c82e70356daf859ff4de11f85d where mc explicitly probes one dir entry and rewinds back. Looks legitimate.
Thanks for checking it, I will bring it upstream to mergerfs.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=81fb614503b6ecd4b25280ceaf1c1357c6e5c0c9 commit 81fb614503b6ecd4b25280ceaf1c1357c6e5c0c9 Author: Piotr Karbowski <slashbeast@gentoo.org> AuthorDate: 2021-02-09 23:33:18 +0000 Commit: Piotr Karbowski <slashbeast@gentoo.org> CommitDate: 2021-02-09 23:34:49 +0000 sys-fs/mergerfs: 2.32.3 bump Closes: https://bugs.gentoo.org/769356 Closes: https://github.com/trapexit/mergerfs/issues/877 Signed-off-by: Piotr Karbowski <slashbeast@gentoo.org> sys-fs/mergerfs/Manifest | 1 + sys-fs/mergerfs/mergerfs-2.32.3.ebuild | 52 ++++++++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+)
