bug#74766: mv cannot move a file from a Linux "portal" file system

[Paul Eggert]

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.