GNOME Bugzilla – Bug 683295
Can't delete some trash files with names containing special chars
Last modified: 2013-10-16 15:39:41 UTC
I can't delete one of the files from gvfs trash with cmdline utilities. My intent was to automate periodic trash cleanup with the following script: $ cat ~/bin/daily #!/bin/sh # fd.o trash cleanup export IFS=$'\n' for file in $(gvfs-ls trash:///) do gvfs-rm trash:///$file done Generally it works ok, but for one of the files in my trash it doesn't work. Here is what I get when running the script: $ ~/bin/daily Error deleting file: No such file or directory Here is the file in the trash: booxter@epbyminw0568t4 ~ $ gvfs-ls trash:/// Non-Programmer%27s_Tutorial_for_Python.pdf I expect the problem to be related to this %27 char sequence which represents a single quote char. I tried several ways to remove the file from the trash with gvfs-rm, but failed too: booxter@epbyminw0568t4 ~ $ gvfs-rm trash:///Non-Programmer%27s_Tutorial_for_Python.pdf Error deleting file: No such file or directory booxter@epbyminw0568t4 ~ $ gvfs-rm trash:///Non-Programmer\%27s_Tutorial_for_Python.pdf Error deleting file: No such file or directory booxter@epbyminw0568t4 ~ $ gvfs-rm trash:///Non-Programmer\'s_Tutorial_for_Python.pdf Error deleting file: No such file or directory booxter@epbyminw0568t4 ~ $ gvfs-rm trash:///Non-Programmer\\\'s_Tutorial_for_Python.pdf Error deleting file: No such file or directory So it seems there is no way to clean up the trash from this file with cmdline tools only. I haven't checked if nautilus would be able to do the job for I don't have any GUI gnome utilities on this machine, but I suppose this should work there (?).
I use gvfs utilities from 1.10.1 Gentoo package. But for what I see in git, there were no serious changes in utilities section since long time ago, so I expect to see the same problem in master too. [Though I can't check it by myself, for this requires a very fresh glib and stuff.]
Just tested here in git master, works fine. $ gvfs-ls -a -l trash:/// Non-Programmer's_Tutorial_for_Python.pdf 0 (regular) $ gvfs-rm trash:///Non-Programmer\'s_Tutorial_for_Python.pdf $ gvfs-rm trash:///Non-Programmer\'s_Tutorial_for_Python.pdf Error deleting file: No such file or directory The difference is an unescaped file name returned from gvfs-ls output. Is this trashed file a recent one or an old one, possibly created by buggy gvfs version? The only change I can find is http://git.gnome.org/browse/gvfs/commit/daemon/trashlib?id=f205f6cfa56dbbc2dac6390bf4cd640ebfe6155c dated back to 2009.
This trash file was created on May 7, 2012 by transmission-gtk (2.50) torrent client (with gvfs-1.10.1, the same version I currently run): booxter@epbyminw0568t4 ~ $ ls .local/share/Trash/files/Non-Programmer%27s_Tutorial_for_Python.pdf -l -rw-r--r-- 1 booxter booxter 206711 May 7 18:08 .local/share/Trash/files/Non-Programmer%27s_Tutorial_for_Python.pdf So it seems it's really named with "%27" in my file system, not with quote char like in your case. I've tried what you did, and it succeeded: booxter@epbyminw0568t4 ~ $ touch Non-Programmer\'s_Tutorial_for_Python.pdf booxter@epbyminw0568t4 ~ $ gvfs-trash Non-Programmer\'s_Tutorial_for_Python.pdf booxter@epbyminw0568t4 ~ $ gvfs-ls -a -l trash:/// Non-Programmer's_Tutorial_for_Python.pdf 0 (regular) Non-Programmer%27s_Tutorial_for_Python.pdf 206711 (regular) booxter@epbyminw0568t4 ~ $ gvfs-rm trash:///Non-Programmer\'s_Tutorial_for_Python.pdf booxter@epbyminw0568t4 ~ $ gvfs-rm trash:///Non-Programmer\'s_Tutorial_for_Python.pdf Error deleting file: No such file or directory So you tested another scenario, hence it worked for you. Here is how you can try to reproduce the issue: booxter@epbyminw0568t4 ~ $ touch Non-Programmer%28s_Tutorial_for_Python.pdf booxter@epbyminw0568t4 ~ $ ls -l Non-Programmer%28s_Tutorial_for_Python.pdf -rw-r--r-- 1 booxter booxter 0 Sep 4 13:39 Non-Programmer%28s_Tutorial_for_Python.pdf booxter@epbyminw0568t4 ~ $ gvfs-trash Non-Programmer%28s_Tutorial_for_Python.pdf booxter@epbyminw0568t4 ~ $ gvfs-ls -a -l trash:/// Non-Programmer%27s_Tutorial_for_Python.pdf 206711 (regular) Non-Programmer%28s_Tutorial_for_Python.pdf 0 (regular) booxter@epbyminw0568t4 ~ $ gvfs-rm trash:///Non-Programmer%28s_Tutorial_for_Python.pdf Error deleting file: No such file or directory booxter@epbyminw0568t4 ~ $ gvfs-rm trash:///Non-Programmer\%28s_Tutorial_for_Python.pdf Error deleting file: No such file or directory booxter@epbyminw0568t4 ~ $
Oh, I see. So in that case, since you're constructing an URI, you need to escape all invalid characters such as the percent sign, e.g. Programmer%27s_Tutorial would become Programmer%2527s_Tutorial: $ gvfs-rm trash:///Non-Programmer%28s_Tutorial_for_Python.pdf Error deleting file: No such file or directory $ gvfs-rm trash:///Non-Programmer%2528s_Tutorial_for_Python.pdf $ gvfs-rm trash:///Non-Programmer%2528s_Tutorial_for_Python.pdf Error deleting file: No such file or directory
Wow. Actually, I don't reconstruct an URI, I use what gvfs-ls provides me with. I expected gvfs tools to be interoperatable and hence useful in scripts. I would suggest gvfs-rm to do it by itself and not bother users. What do you think? Or do you think users should escape special chars by themselves? If so, where can I find the full list of these sequences so that I can enhance my script to handle such special cases?
(In reply to comment #5) > Wow. Actually, I don't reconstruct an URI, I use what gvfs-ls provides me with. > I expected gvfs tools to be interoperatable and hence useful in scripts. Internally, gvfs commandline tools use g_file_new_for_commandline_arg() for constructing GFile objects. Documentation says: > "The value of arg can be either a URI, an absolute path or a relative path resolved relative to the current working directory." The function works two ways: 1. you pass an URI, in that case it must be a valid URI 2. you pass local path, in that case the path is resolved and escaped automatically What you pass in is an invalid URI and utilities can't have logic to correct malformed URI strings. > I would suggest gvfs-rm to do it by itself and not bother users. What do you > think? I think you should better put sed in the pipe. The only possibility would be a new argument for gvfs-ls, returning full URI which then could be easily passed to other utilities. Patches are welcome :-) > Or do you think users should escape special chars by themselves? If so, > where can I find the full list of these sequences so that I can enhance my > script to handle such special cases? Some hint is at http://developer.gnome.org/glib/2.28/glib-URI-Functions.html But we generally follow the standards: http://www.ietf.org/rfc/rfc3986.txt
Created attachment 223818 [details] [review] Patch to add -u option to gvfs-ls to output URIs
I've attached a patch which will add a new -u option for gvfs-ls to output URIs. I've tested it on gnome-2-32 branch only (due to difficulty of building gvfs from master). I'm not sure if this is the right way to send patches for review in the project, if not, please tell me where to send it instead.
Created attachment 223819 [details] [review] Patch to add -u option to gvfs-ls to output URIs
Review of attachment 223819 [details] [review]: Thanks for the patch, please see my comments. Bugzilla is the right place for patches since we have a discussion history here and can do patch review easily using integrated tools. ::: programs/gvfs-ls.c @@ +43,3 @@ { "show-completions", 'c', 0, G_OPTION_ARG_STRING, &show_completions, N_("Show completions"), N_("PREFIX") }, { "nofollow-symlinks", 'n', 0, G_OPTION_ARG_NONE, &nofollow_symlinks, N_("Don't follow symbolic links"), NULL}, + { "print-uris", 'u', 0, G_OPTION_ARG_NONE, &print_uris, N_("Output standards compliant URIs"), NULL}, I'd suggest to rephrase it to something like "Print full URIs" @@ +177,3 @@ while ((info = g_file_enumerator_next_file (enumerator, NULL, &error)) != NULL) { + show_info (info, container_uri); It's much easier to pass "file" in and use g_file_get_child() to construct a child GFile object where you would easily call g_file_get_uri() to get a proper URI. Much better than any string operations.
Created attachment 226902 [details] [review] New patch with review comments addressed
Any news on this patch?