Bug 395023

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

MR to fix this appears to be dead, any good workarounds for mounting a secondary hard drive to avoid trashing moving files to the ssd? The custom desktop entry works ok but you can't bind the delete key to it without some jank. I'd even take running a new filesystem if it has good compression support.

There are a couple of workarounds. You can use trash-cli, althought full compatibility with the dolphin trash menu item is not guaranteed, or you can press shift+delete to delete the files on the spot without moving them to the trash first.

I'm personally slowly moving to bcachefs on my storage drives. It supports RAID for non-uniform drives and has compression.