GNOME Bugzilla – Bug 523139
nautilus does not remove file '_x' from trash
Last modified: 2008-06-11 15:16:13 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/203195 "Steps to reproduce on hardy: 1. Create a file on a partition that is not the home-partition an begins with a '_', e.g. _x or __init__.py $ touch /mnt/Daten/barcc/Projekte/_x 2. $ nautilus /mnt/Daten/barcc/Projekte/ and delete the file (del). Now it is in /mnt/Daten/.Trash-1000/ 3. Now open the Trash: $ nautilus Trash:/// a) Press the 'Empty Deleted Items' button -> All files are removed except the file _x b) Select the file _x and hit DEL and confirm the are-you-sure-dialog. -> Now there is a dialog containing the text: ------------------------------------------------------------- Fehler beim Löschen. Es ist ein Fehler beim Einlesen der Informationen über »mnt_Daten_.Trash-1000___x« aufgetreten. Weitere Details anzeigen Fehler beim Untersuchen der Datei /mnt/Daten/.Trash-1000_/files/x mit fstat(): No such file or directory -------------------------------------------------------------"
Good catch! Moving to gvfs. The issue is that we internally use an escaping mechanism in the trash GVFS backend: gvfsbackendtrash.c:escape_pathname() gvfsbackendtrash.c:unescape_pathname() '/' is converted to '_', and '_' to "__". This implies the following conversions: "/a_b/c" => "_a__b_c" "/a_/c" => "_a___c" "/a/_c" => "_a___c" As you can see, two different file names ar emapped to the same escaped name. Confirming, raising priority.
Created attachment 108285 [details] [review] Proposed patch The attached patch changes the escaping routine to convert "/_" to "__ _" "/ _" to "_ __" "/any-number-of-spaces_" to "/one-space-more_" That said, if we encounter "/_" or "/..._" [where ... is any non-zero number of spaces], we insert an additional stuffing space. Later, during decoding, we will simply remove the stuffing space again. However, in the "/_" case it ensures that we don't decode it to "_/".
Whats wrong with hex escapes ? that seems much more straightforward than this convoluted custom scheme.
*** Bug 529446 has been marked as a duplicate of this bug. ***
Created attachment 110879 [details] [review] Use hex escape codes for trash (un)escape_pathname. In my tests, the attached patch fixes the problem (including being able to delete files in trash deleted with plain gvfs that where stuck in trash). Doing this simple test revealed a minor problem: touch _test _test_ %test% test%25test test%2ftest test%5ftest gvfs-trash *test* They don't pose a problem for cleaning the trashcan, but they show up *unescaped* (without first having been escaped) when you /view/ the trashcan contents!
I should probably mention that the minor problem seems to happen also with plain gvfs 0.2.3, thus not introduced by the patch.
(In reply to comment #5) > Created an attachment (id=110879) [edit] > Use hex escape codes for trash (un)escape_pathname. > > In my tests, the attached patch fixes the problem (including being able to > delete files in trash deleted with plain gvfs that where stuck in trash). > Then we should probably go ahead and use this patch, as it's the right thing to do. > Doing this simple test revealed a minor problem: > touch _test _test_ %test% test%25test test%2ftest test%5ftest > gvfs-trash *test* > > They don't pose a problem for cleaning the trashcan, but they show up > *unescaped* (without first having been escaped) when you /view/ the trashcan > contents! > We definitely escape the string in GIO before adding it to the keyfile, and we definitely unescape the string before we set the display name using it inside of GVFS. The problem is that we only escaped characters into hex encoding inside of GIO, so any already hex-encoded text is passed through untouched (and gets unescaped when set as the display-name inside of GVFS). It's definitely an unintended consequence, but I really don't think it's common enough that we should worry about it over restoring this functionality (it's pretty hard on users). If I'm wrong, please say so, but I can't find a single file on my filesystem that uses hex encoding as a part of its real filename. Any user that might end up confused by this could open the files and inspect them. If the latter really is a problem, we should think about some other encoding scheme, and it will likely require an update of the Trash specification.
(In reply to comment #7) [...] > It's definitely an unintended consequence, but I really don't think it's common > enough that we should worry about it over restoring this functionality (it's > pretty hard on users). All I meant was, this is a bug which I don't care to fix. I was just interested in mentioning to make sure it's knows, since I ran into it. If anyone cares, feel free to open a bugreport about it! :) I'm happy as long as I can empty my trash. Would be nice to see the patch committed and this bug closed. ;)
Gicmo gave permission, so I committed it on your behalf. Thanks! 2008-06-11 A. Walton <awalton@gnome.org> * daemon/gvfsbackendtrash.c (escape_pathname), (unescape_pathname): Use hex escapes in the trash backend. Patch by Andreas Henriksson. Fixes bug #523139.