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.
