SUMMARY As Christoph Feck explained [1]: > if you are trying to delete files > inside trash:// KIO slave instead of using the file:// slave, then it > probably cannot work because the encoding hack to support broken file names > was only added for the file:// slave. STEPS TO REPRODUCE 1. Move a file with a broken file name to the trash -> Within Dolphin it can be deleted if the trash folder is opened by file:// -> But not within trash:// SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.17.2 KDE Frameworks Version: 5.64.0 Qt Version: 5.13.1 ADDITIONAL INFORMATION [1] https://bugs.kde.org/show_bug.cgi?id=410576#c16
*** Bug 430313 has been marked as a duplicate of this bug. ***
I wonder if instead of adding another LegacyCodec instance to kio_trash (and possibly TrashImpl, as otherwise the user can trash the file but won't be able to empty the Trash), it would make more sense to inform the user that this file has some weird characters in its name and that it's a good idea to rename it to prevent future problems with it.
What if they don't want to? The way I see it we don't get around solving the issue that trash can't delete some files one way or the other. We can't just rename files for the user without asking, the file may be encoded this way for a reason and changing it might break other consumers, and the user may for the same reason choose to not follow our advise. So, I don't see a way around adding encoding support. Being ignorant of how trash works I can't help but wonder why trash reimplements logic that exists in file:// though. If I was to implement a trash slave from scratch I'd most definitely have it call out to file behind the scenes. It's merely a more purpose-driven file slave, is it not?