GNU bug report logs -
#74766
mv cannot move a file from a Linux "portal" file system
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 283 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.