GNOME Bugzilla – Bug 644604
Evince trunk can not do subsequent open of filenames/directories containing various characters
Last modified: 2011-03-20 10:22:23 UTC
While looking at bug #643843 I noticed a problem with brackets in filenames that do not just have an effect on CBZ files, but files such as PDFs as well. If I have a number of files and directories with brackets in their name, the first load of one of these files works fine. The problem is on subsequent loads of files with a bracket in their name. Then I get an "Unable to open document - Error opening file: No such file or directory" error. The problem is not with the filename, but if the file is not the first one loaded. Session 1: Load pdft[es]t.pdf Loads fine Load pdf[test.pdf Error opening file..... Close evince Session 2: Load pdf[test.pdf Loads fine Load pdft[es]t.pdf Error opening file... I put some printf's in evince and looked at the URI of the files. In the first load it has the normal filename The problem is the percentage sign gets pulled out the second time around. The good one: pdf%Btes%Dt.pdf becomes this: pdfBtesDt.pdf and then there is an error.
If we look at ev_application_open_uri_at_dest(), the uri is run as normal during the first load of a file. If a new file is loaded however within this function, we go to ev_spawn(), where the uri is heavily reconstructed. This would be an obvious point where the percentage signs could disappear.
Created attachment 183267 [details] [review] Calls g_app_info_launch_uris instead of g_app_info_launch The problem is with the g_app_info_launch call in ev_spawn(). According to http://library.gnome.org/devel/gio/2.28/GAppInfo.html#g-app-info-launch - "Some URIs can be changed when passed through a GFile (for instance unsupported uris with strange formats like mailto:), so if you have a textual uri you want to pass in as argument, consider using g_app_info_launch_uris() instead." This is what happened, the percentage sign in the URI disappeared when it was passed to g_app_info_launch. It was munged in the arg's passed to main() in the spawned call, I checked. This patch used g_app_info_launch_uris instead, as the documentation recommends. -- Dennis Sheil P.S. The only line in my patch which I went back and forth on was: + gl_uri=g_list_append(gl_uri, (gpointer)uri); uri comes into ev_spawn() as the parameter "const char *uri". I considered passing it to g_list_append with g_strdup, but opted instead to cast it. If you want to change the approach of passing uri to g_list_append to the g_strdup one, or some other one that you think is better, that is fine.
I changed the name of the bug since this affects more than filenames or directories with a bracket in their name. I have listed many of the characters affected below. Again: Evince can load on its first try virtually any filename or URI. It is when it tries to spawn a new evince instance with g_app_info_launch for a second or third file that it fails. Because GAppInfo is not passing the URI properly. I initially ran across the failures on directories or filenames containing the bracket characters - [ and ]. But actually, the failure is across filenames and directories that contain any of these characters: [ ] ` ^ < > | ; ? % \ { } # Again, this is not the case for the first file loaded by evince, but for any subsequent file loaded by evince. My patch ( https://bugzilla.gnome.org/attachment.cgi?id=183267&action=diff ) corrects the behavior, sending the URI properly through the proper call. -- Dennis
Created attachment 183694 [details] [review] Same patch for g_app_info_launch_uris, with better whitespace This is the same patch as 183267, but I cleaned up the whitespace (using the file's existing whitespace formatting with tabs etc.) for it.
I can't reproduce it, but patch looks sane anyway, so I've just pushed a slightly different patch (fixing coding style and memory leak). Thanks!