https://bugs.kde.org/show_bug.cgi?id=395023
--- Comment #11 from m...@mwsys.mine.bz --- (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 -- You are receiving this mail because: You are watching all bug changes.
