GNOME Bugzilla – Bug 687540
In Trash folder, Nautilus misinterprets "\n" in filename as a line break
Last modified: 2012-11-09 13:41:48 UTC
1. Create a file or folder with the name "a\nb". 2. Move it into the Trash. 3. Open the Trash and find it. What happens: 1. The name appears correctly as "a\nb". 3. The name appears incorrectly as a b What should happen: The name appears as "a\nb" in both cases. Curiously, the error occurs only in the Trash folder. It occurs regardless of whether the Trash is using Icons, List, or Compact view.
Same thing happens here
Could you please test this with 3.6.1? (As you've set the version field of this bug report to 3.5)
ok, I spent quite a while tracking this through Nautilus and it seems the that the GFileInfo object given by the g_file_enumerate_children_async call is returning the wrong display name for the directorys in Trash. For example: g_file_info_get_display_name (info) returns: a b but g_file_info_get_name (info) returns the correct: a\nb Anyway it seems that the error is in GIO so will reassign for now. Maybe someone who knows GIO better might be able to track this down faster than me.
I believe this due to how GIO and gvfs cooperate wheh trashing a file. The display name in this case comes from the ".trashinfo" files in ~/.local/share/Trash/info GIO seems to do [1] when trashing the file, but gvfs parses the trashinfo with g_uri_unescape_string() [2]. I am not sure what's the best way to solve this, CC-ing Ryan. [1] http://git.gnome.org/browse/glib/tree/gio/glocalfile.c#n1737 [2] http://git.gnome.org/browse/gvfs/tree/daemon/trashlib/trashitem.c#n174
Ok so I installed KDE desktop and trashed the a file with a similar name. The first thing I noticed is "a\nb" that was trashed in gnome appears with a strange character in place of "\n" and the directory I trashed in KDE appears in KDE trash correctly. Next I logged back into Gnome and again the KDE trashed directory appeared correctly in the Nautilus trash so it seems that gvfs is doing the right thing and its GIO that it not behaving correctly.
KDE encodes "b\nc" as "b%5Cnc" in the .trashinfo file. Is there any reason why GIO shouldn't just use g_uri_escape_string ?
Created attachment 228561 [details] [review] Use-url-encoding-for-trash-fileinfo-path-as-per-freedesktop-specification I have attached a fix for this bug that implements the encoding as per the freedesktop trash specification found here: http://freedesktop.org/wiki/Specifications/trash-spec And is also confirmed by the KDE implementation of the specification: https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/master/entry/kioslave/trash/trashimpl.cpp#L281
So the issue gets caused on the gvfs trash side which sees the literal string 'a\nb' in the keyfile and interprets the "\n" as a newline (possibly in GKeyFile?) The \ gets through the current algorithm because it's a printable. It just happens to not be permitted by URI escaping, which manages to dodge the issue. The real fix here is to modify the gvfs side to not unescape the \n in the keyfile... On the other hand, we could argue that anyone who writes a '\' into a field that's supposed to be URI escaped has acted in violation of the spec and we're free to do whatever we want there... making the change as suggested here would also bring us in-line with what KDE is doing, anyway....
Review of attachment 228561 [details] [review]: In short: please commit. If someone wants to go over the interaction of the trash specification and the desktop file specification with a fine-tooth comb to find out about what exactly "\n" in a string means, then please be my guest... :)