Bug 395023 - $topdir/.Trash not created or used on btrfs sub-volumes
Summary: $topdir/.Trash not created or used on btrfs sub-volumes
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: Trash (show other bugs)
Version: unspecified
Platform: Archlinux Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
Depends on:
Reported: 2018-06-04 10:20 UTC by Thomas H.
Modified: 2023-01-21 14:59 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:

Example Dolphin trash ext4 and btrfs (1.02 MB, video/x-matroska)
2021-12-11 10:51 UTC, Schlaefer

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas H. 2018-06-04 10:20:26 UTC
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:
- @root      (btrfs subvolume mounted to /)
- @home      (btrfs subvolume mounted to /home)
- @workspace (btrfs subvolume mounted to /home/Workspace)

And file-system layout
/home/Workspace/.Trash (Permissions: drwxrwxrwt)
/.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)
Comment 1 Thomas H. 2018-06-04 10:35:50 UTC
Might also be related to this issue:
Comment 2 Schlaefer 2021-12-11 10:51:47 UTC
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
Comment 3 Francesco 2022-05-17 05:44:43 UTC
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.
Comment 4 Emanuele 2022-05-18 20:12:35 UTC
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
Comment 5 Schlaefer 2022-11-14 16:20:51 UTC
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

[Desktop Action moveToTrash]
Name=Move To 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