On 2024-12-10 05:59, Bruno Haible via GNU coreutils Bug Reports wrote:
newfstatat(AT_FDCWD, "/run/user/1000/doc/1316905f/jas-key.gpg", {st_mode=S_IFREG|0664, st_size=7335, ...}, AT_SYMLINK_NOFOLLOW) = 0
This means /run/user/1000/doc/1316905f/jas-key.gpg is a regular file and its name can be resolved without symlink loops.
openat(AT_FDCWD, "/run/user/1000/doc/1316905f/jas-key.gpg", O_RDONLY|O_NOFOLLOW) = -1 ELOOP (Too many levels of symbolic links)
This means /run/user/1000/doc/1316905f/jas-key.gpg is a symlink, or there is a symlink loop when resolving /run or /run/user or ... or /run/user/1000/doc/1316905f. Which obviously contradicts the newfstatat results.
I don't understand the result of the openat() system call.
Yes, it looks like a filesystem bug. I see a similar bug reported (but incorrectly diagnosed) here:
https://github.com/flatpak/xdg-desktop-portal/issues/1117
$ cp /run/user/1000/doc/1316905f/jas-key.gpg . works fine.
Presumably this is because cp uses "openat(AT_FDCWD, "/run/user/1000/doc/1316905f/jas-key.gpg", O_RDONLY)", i.e., cp doesn't use the O_NOFOLLOW flag and so it sidesteps the filesystem bug.
Assuming it's a FUSE portal filesystem, the bug could be either in the Linux FUSE kernel module, or (more likely) in the user-space code. I assume you are using GVFS, and I reproduced a similar problem, so I filed a bug report with the GVFS folks here:
https://gitlab.gnome.org/GNOME/gvfs/-/issues/774 I don't see how coreutils could easily work around these filesystem bugs.