Bug 496142 - new mv xattr-preservation behavior can be very noisy ....
new mv xattr-preservation behavior can be very noisy ....
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 496143
  Show dependency treegraph
 
Reported: 2009-04-16 16:23 EDT by Eric Sandeen
Modified: 2009-12-25 10:42 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 496143 (view as bug list)
Environment:
Last Closed: 2009-04-17 09:48:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Eric Sandeen 2009-04-16 16:23:51 EDT
In the latest coreutils it attempts to preserve xattrs, and it can lead to very noisy output if the target filesystem does not support xattrs (or, perhaps, does not support selinux xattrs):

root@inode tmp]# mv newdir/ mnt/
mv: setting attributes for `mnt/newdir/file58': Operation not supported
mv: setting attributes for `mnt/newdir/file85': Operation not supported
mv: setting attributes for `mnt/newdir/file68': Operation not supported
mv: setting attributes for `mnt/newdir/file74': Operation not supported
mv: setting attributes for `mnt/newdir/file1': Operation not supported
mv: setting attributes for `mnt/newdir/file69': Operation not supported
mv: setting attributes for `mnt/newdir/file95': Operation not supported
mv: setting attributes for `mnt/newdir/file42': Operation not supported
mv: setting attributes for `mnt/newdir/file77': Operation not supported
mv: setting attributes for `mnt/newdir/file44': Operation not supported
mv: setting attributes for `mnt/newdir/file38': Operation not supported
mv: setting attributes for `mnt/newdir/file36': Operation not supported
mv: setting attributes for `mnt/newdir/file31': Operation not supported
mv: setting attributes for `mnt/newdir/file25': Operation not supported
mv: setting attributes for `mnt/newdir/file57': Operation not supported
mv: setting attributes for `mnt/newdir/file32': Operation not supported
mv: setting attributes for `mnt/newdir/file100': Operation not supported
mv: setting attributes for `mnt/newdir/file89': Operation not supported
.....
mv: setting attributes for `mnt/newdir/file96': Operation not supported
mv: setting attributes for `mnt/newdir': Operation not supported
[root@inode tmp]#

This would happen when copying to a filesystem that does not support selinux, or does not support xattrs - fat, cifs, nfs, mounts with selinux contexts ...

mv /home/myphotos /mnt/vfat-usbstick for example would probably trigger this.

I'm not sure it's worth issuing a warning for every file if the target doesn't support the thing mv is trying to preserve.  For that matter maybe mv should stop trying after the first EOPNOTSUPP?

Thanks,
-Eric
Comment 1 Ondrej Vasik 2009-04-17 04:39:06 EDT
Thanks for report, as there is already a way to silent error messages from xattr's preserving (done for cp -a), it could be easily used for mv as well... will do that...
Comment 2 Ondrej Vasik 2009-04-17 09:48:20 EDT
Reported upstream, patch which fixes the issue via reduce_diagnostics (comment#1) was rejected, I proposed another patch which should behave the same way as already accepted SELinux diagnostic suppresing (not showing them for ENOTSUP and ENODATA errors), waiting for review. Anyway built with it in Rawhide as coreutils-7.2-2.fc12, closing RAWHIDE - as this message spam is unacceptable and has to be solved somehow.
Comment 3 Eric Sandeen 2009-04-17 09:57:44 EDT
Thanks.  If this exists in F11, is it worth trying to get an exception to make the change there post-freeze?

-Eric
Comment 4 Ondrej Vasik 2009-04-17 10:09:48 EDT
Will see on Monday - if accepted that way, it's small change and maybe could be fixed/tagged for F-11 final - or at least done via 0day update
Comment 5 Eric Sandeen 2009-04-17 11:07:15 EDT
Thanks, yep 0day is probably fine too.

Note You need to log in before you can comment on or make changes to this bug.