Bug 515582 - Option for switching kf.kio.workers.trash to old behavior
Summary: Option for switching kf.kio.workers.trash to old behavior
Status: REPORTED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: Trash (other bugs)
Version First Reported In: 6.22.0
Platform: NixOS Linux
: NOR wishlist
Target Milestone: ---
Assignee: KIO Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-02-05 22:36 UTC by Thomas Baag
Modified: 2026-02-06 18:03 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.