On 15/08/2026 18:21, Jean-Francois Dockes via GNU coreutils Bug Reports wrote:
Paul Eggert writes:
> On 12/11/23 12:03, Abraham S.A.H. via GNU coreutils Bug Reports wrote:
> > a sane default behaviour regarding extended attributes in mv and others?
>
> What's wrong with the default behavior in current GNU mv? Please give a
> specific example (specify platform, filesystems, mv version, etc.).
mv still silently discards the extended attributes when asked to move a file
from
e.g. an ext4 fs to e.g., a VFAT one.
Again: the data is gone. mv lost the data.
For example (on Ubuntu 26.04, but this is probably irrelevant):
hm3$ mv --version
mv (GNU coreutils) 9.7
Packaged by Ubuntu (9.7-3ubuntu2)
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Mike Parker, David MacKenzie, and Jim Meyering.
hm3$ getfattr myfile.txt
# file: myfile.txt
user.myattr
hm3$ mv myfile.txt /run/media/dockes/C052-0E64/
hm3$ getfattr /run/media/dockes/C052-0E64/myfile.txt
hm3$ mv /run/media/dockes/C052-0E64/myfile.txt .
hm3$ getfattr myfile.txt
mv just casually discarding data...
You are asking what's wrong. IMO this is wrong.
If the target file system is full ("No space left on device"), mv keeps the
original file. It should do the same for an extended attribute problem.
Well there is lots of metadata dropped when copying to vfat.
For example mv already warns for each failed chown which would happen for
a root user copying files:
mv: failed to preserve ownership for 'dest/file1': Operation not permitted
mv: failed to preserve ownership for 'dest/file2': Operation not permitted
...
Also all mode bits are mapped to a single mode, and chmod(2) is essentially
ignored
so we can't warn about that unless we had an extra verification stat(2).
Note ACLs are generally permissions related so we wouldn't want to warn
about all extended attributes I think?
We do have support in gnulib for distinguishing basic ACLs IIRC.
Note cp does give warnings if you explicitly ask it to preserve xattrs:
$ cp --preserve=xattr file.attr vfat/
cp: setting attributes for 'vfat/file.attr': Operation not supported
So if one really cares you could cp with granular options, and then rm.
We could potentially require xattr preservation in mv,
but not by default given how disparate support for xattrs is.
I suppose one thing we could consider is to warn once per mv invocation.
Note doing that for the chown above is awkward as the error is EPERM.
Note --verbose is another flag which may be a factor here.
cheers,
Padraig
