It seems like kio does neither create nor detect existing $topdir/.Trash(-$uid) directories as mandated by the freedesktop.org trash specification when it comes to btrfs subvolumes. This is problematic because it means files will to be moved across subvolume boundaries, which means the files will actually be copied to ~/.local/share/Trash (and deleted in its original location afterwards). Eg. with the following btrfs layout: /dev/sda1 - @root (btrfs subvolume mounted to /) - @home (btrfs subvolume mounted to /home) - @workspace (btrfs subvolume mounted to /home/Workspace) And file-system layout /bin /boot [...] /home /home/Documents /home/Downloads [...] /home/Workspace /home/Workspace/.Trash (Permissions: drwxrwxrwt) /home/.local/share/Trash [...] /.Trash (Permission: drwx-----T) [...] When deleting a file under workspace it will actually be moved (across the subvolume boundary) into /home/.local/share/Trash and not /home/Workspace/.Trash My guess is that kio does not "detect" (or treat) btrfs subvolumes as individual partions, thus there is no check happening. (Compare LVM issue described here: https://bugs.kde.org/show_bug.cgi?id=178479)
Might also be related to this issue: https://bugs.kde.org/show_bug.cgi?id=248222
Created attachment 144446 [details] Example Dolphin trash ext4 and btrfs This is also not limited to subvolumes of the same root, but happens between different mediums too. The attachment shows two external media, one ext4 (external trash is used) and the other one btrfs (file is copied to the internal trash). Dolphin Version 21.12.0 Operating System: EndeavourOS KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 Kernel Version: 5.15.7-zen1-1-zen (64-bit) Graphics Platform: Wayland
I can confirm the same exact issue, verified today on this two systems: (my main laptop) Operating System: Arch Linux KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 Kernel Version: 5.17.7-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-3630QM CPU @ 2.40GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4000 (testing virtual machine) Operating System: KDE neon 5.24 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 Kernel Version: 5.13.0-41-generic (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i7-3630QM CPU @ 2.40GHz Memory: 3.8 GiB of RAM Graphics Processor: SVGA3D; build: RELEASE; LLVM; I verified it either on external btrfs volume connected via usb or an image file with btrfs on it. When I delete a file this is moved to ~/.local/share/Trash instead to .Trash-1000 on the original btrfs volume.
I confirm on filesystem Btrfs, also reproduced on a filesystem FAT, is it expected? Test: Virt-Manager OS: Fedora 36 Dolphin 21.12.2 KDE Frameworks 5.91.0
trash-cli [1] handles it correctly btw. So if you're affected, install trash-cli, create e.g. ~/.local/share/kservices5/ServiceMenus/moveToTrash.desktop with: --- [Desktop Entry] Name=Move To Trash Type=Service MimeType=all/all; ServiceTypes=KonqPopupMenu/Plugin Actions=moveToTrash X-KDE-Priority=TopLevel [Desktop Action moveToTrash] Name=Move To Trash Icon=org.kde.plasma.trash Exec=trash %U --- creates a new "Move to Trash" context menu item that offers a workaround until this gets resolved. [1] https://github.com/andreafrancia/trash-cli
Given that I don't care about btrfs, let me un-assign this bug from myself to avoid any false hopes.
I plan to work on this, if nobody else is working on it. But nothing quick promised (probably will take a few weeks).
Did some debugging, and it turns out the issue is rather complicated. The current code checks for the mount point of a path using two conditions (https://invent.kde.org/frameworks/kio/-/blob/c43c6a06d25d8281bc898eb0ba3032840bf9d53b/src/core/kmountpoint.cpp#L442) 1. The device id of the mount point (as reported in /proc/self/mountinfo) needs to match the device id of the path 2. The path needs to start with the path of the mount point. However, for btrfs, the device id of the mount point reported by stat and in mountinfo are different (see references). In my view, this leaves us with the following options: 1. Resolve this as WON'T FIX 2. Revert to the old behavior of not using device id, and only using the longest matching prefix to find the mount point of a path. (https://invent.kde.org/frameworks/kio/-/merge_requests/503) 3. Find some other way to find the mount point of a path. Would other developers/contributors be able to comment on this? Thanks! References: https://bugzilla.redhat.com/show_bug.cgi?id=711881 https://stackoverflow.com/questions/39494077/linux-stat2-call-gives-non-existing-device-id https://linux-btrfs.vger.kernel.narkive.com/AXOOKc9G/why-does-stat-return-invalid-st-dev-field-for-btrfs
Unassigned myself because I just realized Michael Saxl is already working on this: https://invent.kde.org/frameworks/kio/-/merge_requests/1422
wow, the bug kio not handling btrfs is old.. The only thing that made me notice that a kdevelop crash triggered by a new method isOnCifs that could not handle "not found" mountpoints, the very same root cause of this issue.. anyhow https://invent.kde.org/frameworks/kio/-/merge_requests/1422 would implement btrfs handling: "subvolume-less" roots and explicitly mounted subvolumes are straight forward. What I also do is search for implicitly mounted subvolume "roots" and return that as mountpoint, so cross mountpoint moves should not occur
(In reply to mike from comment #10) > wow, the bug kio not handling btrfs is old.. > The only thing that made me notice that a kdevelop crash triggered by a new > method isOnCifs that could not handle "not found" mountpoints, the very same > root cause of this issue.. > > anyhow https://invent.kde.org/frameworks/kio/-/merge_requests/1422 would > implement btrfs handling: > "subvolume-less" roots and explicitly mounted subvolumes are straight > forward. > What I also do is search for implicitly mounted subvolume "roots" and return > that as mountpoint, so cross mountpoint moves should not occur I have good and bad news for you: with the MR above the .Trash-$UID directory is created (if permissions allow of course). It seems that when the file is moved to the trash the solid framework is used to find the "storage media". That has no idea what to do with subvolumes of any kind. It would be probably possible for solid to find every explicitly mounted subvolume, but enumerating every subvolume is simply not possible, so this will never fully work is the "move to trash" is based on solid. The simplest case (external btrfs, only one subvolume mounted) works. Put simply: if you see a drive icon in dolpin, exactly that subvolume will work, every other will land in .local/share... even though the .Trash-$UID directories are created
To really fix this I need some help from the kde team deciding if/how solid should be changed... Solid Frameworks has also wrong assumptions about btrfs. looking at https://invent.kde.org/frameworks/solid/-/blob/master/src/solid/devices/backends/udisks2/udisksstorageaccess.cpp?ref_type=heads baseMountPoint looks for the (first) mountpoint that has its root in /. This is a wrong assumption with btrfs in multiple ways: first there might be multiple filesystem roots mounted from the same device, second the "root" of the filesystem does not need to be mounted (actually on my system it is not) second even tough udiskctl lists every mountpoint of a filesystem/device, solid only filters the btrfs root "/", if there are multiple and "/" is not mounted, then the first. the MR for KMountPoint will fix this issue partially but create another (minor) one: for every subvolume a .Trash directory will be created but it will be only used if it matches with solid's view. This could be fixed by a second MR that changes kio trash that is checks if solid mount and kmountpoint match. if not than no trash directory should be created.
*** Bug 474680 has been marked as a duplicate of this bug. ***
*** Bug 479525 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1537