Bug 342152 - Move operations from one btrfs subvolume to another do not preserve xattr data
Summary: Move operations from one btrfs subvolume to another do not preserve xattr data
Status: RESOLVED DUPLICATE of bug 116617
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-23 12:32 UTC by David M
Modified: 2020-02-26 21:58 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David M 2014-12-23 12:32:16 UTC
Move operations normal are supposed to preserve xattr data and indeed they do when on the same filesystem.  However in moving files across btrfs subvolumes when using dolphin the xattr does not seem to be preserved.  This is bad because the baloo tagging and rating system now uses xattr data and it means users can unexpectedly lose a lot of work (if thousands of files are tagged or rated).  Baloo no longer seems to keep a backup in a database so it is totally lost after this happens without any warning to the user.



Reproducible: Always

Steps to Reproduce:
1. Use Dolphin to tag or rate file on btrfs subvolume A.
2. Verify xattr data with 'getfattr -d <filename>'
3. Use Dolphin to cut the file from #1 above.
4. Attempt to paste the item above on to a different btrfs subvolume B.
5. Verify lack of xattr data on newly pasted file with 'getfattr -d <filename>'
optional: Do the same as above but on the SAME btrfs subvolume and note that it works then.


Actual Results:  
The xattr data is apparently lost when moving files across btrfs subvolumes.  This is an actual use case as for example it might be done to transfer OS installs or recover from a backup.  Note in this particular case no btrfs snapshots were used.

Expected Results:  
If at all possible xattr data should be preserved when using dolphin.  If not perhaps a warning should be given to the user prior to the operation so that data is not silently lost.

kde-base/dolphin 4.14.3

Linux 3.17.7-gentoo #2 SMP Sun Dec 21 21:40:18 EST 2014 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux

btrfs /etc/fstab entry (mounting options) :

/dev/sda        /       btrfs   device=/dev/sda,device=/dev/sdb,device=/dev/sdc,device=/dev/sdd,rw,autodefrag,compress=lzo,noatime,thread_pool=16,subvol=gentoo       0       0
Comment 1 Christoph Feck 2014-12-23 15:35:05 UTC
Is the issue also visible when using "kioclient move src dest" in Konsole?
Comment 2 David M 2014-12-23 22:08:10 UTC
Yes.  It appears the issue is still present when using "kioclient move src dest" in Konsole:

---
$ touch test
(my note: at this point I then rated the file 4 stars in Dolphin)
$ getfattr -d test
# file: test
user.baloo.rating="8"

$ kioclient move ./test /mnt/archbtrfs/home/david/
$ getfattr -d /mnt/archbtrfs/home/david/
$ ls -l /mnt/archbtrfs/home/david/
total 0
drwxr-xr-x 1 david users 0 Dec 23 09:37 Desktop
-rw-r--r-- 1 david david 0 Dec 23 16:58 test
(my note: At this point I also verified on the destination subvolume the file appears with no rating)
---

Also I should probably add that although these are separate subvolumes they are still on the same btrfs disk array itself.  In other words there is one default root (id=5) subvolume and another subvolume below that called 'gentoo'.
Comment 3 David M 2014-12-26 16:30:27 UTC
I have also verified that 'cp -a --preserve=xattr <source> <dest>' is indeed able to preserve the xattr data (which holds baloo ratings and tags) across btrfs subvolumes.  So it appears likely the issue is something related to Dolphin and not just due to the btrfs filesystem.  Please see below.

----

$ touch testfile
$ ls -l testfile
-rw-r--r-- 1 david david 0 Dec 26 11:21 testfile

[my note: at this point I rated 'testfile' five stars in Dolphin]

$ getfattr -d testfile
# file: testfile
user.baloo.rating="10"

$ cp -a --preserve=xattr  ./testfile /mnt/archbtrfs/home/david/
$ getfattr -d /mnt/archbtrfs/home/david/testfile
getfattr: Removing leading '/' from absolute path names
# file: mnt/archbtrfs/home/david/testfile
user.baloo.rating="10"
-----
Comment 4 Emmanuel Pescosta 2014-12-28 19:57:40 UTC
Thanks for the bug report!

KIO doesn't preserve extended attributes (yet).
Comment 5 Pascal R. 2015-06-25 15:45:56 UTC
It seems like KIO preserves xattrs when moving files between locations on same mount point. This also seems to be unrelated to btrfs.

But when moving between mount points, xattrs are lost. This also happens, if mount points are mounting the same block device.

For example xattrs gets preserved, when movin a file from one directory to another on /home partition:

$ xattr -l /home/A/test.txt
user.xdg.tags: testtag
$ kioclient move /home/A/test.txt /home/B/test.txt
$ xattr -l /home/B/test.txt
user.xdg.tags: testtag

But when remounting the /home partition to /mnt, xattrs gets lost:

$ mount | grep /home
/dev/sda8 on /home type ext4 (rw,relatime,data=ordered)
$ mount /dev/sda8 /mnt
$ xattr -l /home/A/test.txt
user.xdg.tags: testtag
$ kioclient move /home/A/test.txt /mnt/B/test.txt
$ xattr -l /mnt/B/test.txt
=> tag is gone.

Tested on Kubuntu 15.04 with updates from kubuntu-ppa/backports:

$ kioclient --version
Qt: 4.8.6
KDE: 4.14.8
KIO-Client: 2.0
Comment 6 Störm Poorun 2017-04-05 09:59:10 UTC
This bug is fairly serious.

It results in unexpected data loss when simply moving files.

It occurs on ext file systems too.
Comment 7 Nate Graham 2018-01-28 02:19:07 UTC

*** This bug has been marked as a duplicate of bug 116617 ***
Comment 8 tagwerk19 2020-02-26 21:58:14 UTC
*** This bug has been confirmed by popular vote. ***