Bug 515582

Summary:	Option for switching kf.kio.workers.trash to old behavior
Product:	[Frameworks and Libraries] frameworks-kio	Reporter:	Thomas Baag <bugs.kde.org>
Component:	Trash	Assignee:	KIO Bugs <kio-bugs-null>
Status:	REPORTED ---
Severity:	wishlist	CC:	kdedev, kdelibs-bugs-null, oliver.schramm97, voidpointertonull+bugskdeorg
Priority:	NOR
Version First Reported In:	6.22.0
Target Milestone:	---
Platform:	NixOS
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=518012 https://bugs.kde.org/show_bug.cgi?id=517795
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Thomas Baag 2026-02-05 22:36:18 UTC

SUMMARY

The way kf.kio.workers.trash works has changed in december 2025. The old behavior surely wasn't perfect but the new one gives me major headache.

It boils down to the trash being broken for me where it worked correctly before. And it is working now where it was broken before. Problem is: the broken part for me was neglectable before. And the newly broken part is like 99% of my setup.

I have a lot of bind mounts. Way more than physical devices or btrfs subvolumes (excluding snapshots). Those bind mounts have different "st.stx_mnt_id" for the same device. Also my btrfs subvolumes are not bind mounted. So "st.stx_mnt_id" stays the same even for somewhat separate storages. The new implementation is more flawed than the old one in my opinion.

People are complaining also for other filesystems like ext4 and xfs.[1] Their workaround applied to my setup would mean I have to create like 10 extra bind mounts from "$FOLDER/.Trash-UID" to ".local/share/Trash" for each system I use. I don't use just one laptop.

The XDG design specs say it's ok to fallback to ".local/share/Trash". It's a very simple thing to do and worked ok for decades. A better solution needs to be more complex than what was done with the recent changes. And I don't know if it's worse it. Just let me have the old one.

Please give us an option to switch to the old behavior. Or just add an option to fallback to trash when the new algorithm fails. This way we have a choice. Remember KDE was known for the many choices to fit the system to your needs.

I don't want to maintain a fork of kio (which would pull in a lot of other stuff). I already need to use forked Dolphin so it's not driving me nuts with random behavior introduced by a change which won't be fixed :/

STEPS TO REPRODUCE (one of the problems stated)
1. mkfs.btrfs bla
2. mkdir blubb
3. mount bla blubb
4. btrfs subvolume create blubb/home
5. compare "st.stx_mnt_id" for blubb and home

OBSERVED RESULT
They are the same.

EXPECTED RESULT
This is the expected result so it shouldn't be used to find some trash folder. Please.
(ktrash would look at "blubb/.Trash" to trash stuff from "blubb/home" which is a different subvolume)

[1] https://discuss.kde.org/t/kioworker-no-trash-directory-found-for-trashimpl-findtrashdirectory-returned-3-on-secondary-drives/42597/8

Comment 1 Thomas Baag 2026-02-05 23:17:06 UTC

I think a "one size fits all" solution would involve some filter by which users can specify manually where trash will go. Maybe some users want their small files delete on NFS go into my "$HOME/.local/share/Trash", even if it would need a copy from remote to local? Not the craziest idea if you ask me.

Comment 2 TraceyC 2026-02-06 18:03:07 UTC

Changing this to wishlist, since it's a feature request rather than a bug.

Comment 3 Oliver Schramm 2026-04-15 13:32:43 UTC

Hey,

I agree fully with this! KDE is about choice to me. Trashing is opinionated and the XDG spec is very flawed. So I plan to implement an option for defaulting to fallback.

I'm just wondering right now: has the situation improved with KIO 6.23 in March? It should work a lot smoother now and for most users without any workarounds.

Comment 4 Thomas Baag 2026-04-15 16:06:09 UTC

After the issue was changed to wishlist I just patched "trashimpl.cpp" myself to fall back to "m_trashDirectories[0]". I just tested it without my patch and tried to delete something in my $HOME/Downloads. It still complained about not finding a trash for "/" (which btw. isn't the correct mountpoint for Downloads either) and wants to delete instead of move to trash. I tested KIO 6.23.0.