Bug 413834

Summary:	Add "encoding hack to support broken file names" for trash://
Product:	[Frameworks and Libraries] frameworks-kio	Reporter:	postix <postix>
Component:	Trash	Assignee:	David Faure <faure>
Status:	CONFIRMED ---
Severity:	normal	CC:	a.samirh78, bugseforuns, cfeck, faure, kdelibs-bugs, kfm-devel, meven29, nate, postix, sitter, thiago
Priority:	NOR
Version:	5.64.0
Target Milestone:	---
Platform:	Other
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=410576
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description postix 2019-11-05 11:48:23 UTC

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

Comment 1 Christoph Feck 2020-12-18 11:10:18 UTC

*** Bug 430313 has been marked as a duplicate of this bug. ***

Comment 2 Ahmad Samir 2021-06-17 18:44:09 UTC

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.

Comment 3 Harald Sitter 2021-06-18 15:37:44 UTC

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?