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