GNOME Bugzilla – Bug 769649
evince can't open a PDF file with a : in the name
Last modified: 2018-03-13 12:38:02 UTC
Take a copy of your favorite PDF file and rename it to something which has a colon character in the name such as: file:withcolon.pdf Try to open it from the command line: $ evince file\:withcolon.pdf evince displays its red banner of failure: Unable to open document “file:///tmp/evince-16746/document.ZF2VLY withcolon.pdf”. Operation not supported. Workaround: Start evince from the command line with just: $ evince and then use File -> Open ... to get to selection the file you want and then click on the 'Open" button to successfully open the same file.
FYI, ifyou do $ evince ./file\:withcolon.pdf it works.
Confirmed (and understood). But I believe there should be consistency here as $ evince filewithoutcolon.pdf works just fine without me having to prepend "./" to the filename. Thanks.
I suspect the issue is in gvfs or how evince interacts with gvfs. A colon is the separator of the protocol. Thus "file:withcolon.pdf" may be interpreted as the 'file' protocol whose filename is 'withcolon'. Which does not happen when the file name is prepend with the path './', which makes it unequivocally clear that is a local file.
The issue is how GIO builds a GFile, which is: static GFile * new_for_cmdline_arg (const gchar *arg, const gchar *cwd) { GFile *file; char *filename; if (g_path_is_absolute (arg)) return g_file_new_for_path (arg); if (has_valid_scheme (arg)) return g_file_new_for_uri (arg); if (cwd == NULL) { char *current_dir; current_dir = g_get_current_dir (); filename = g_build_filename (current_dir, arg, NULL); g_free (current_dir); } else filename = g_build_filename (cwd, arg, NULL); file = g_file_new_for_path (filename); g_free (filename); return file; } And has_valid_scheme() checks for valid scheme characters and colon. So, it creates the file using g_file_new_for_uri(). To fix this issue, we would need to implement a helper that checks the special case of 'file:' without '//', and call g_build_filename() and g_file_new_for_path().
*** Bug 780514 has been marked as a duplicate of this bug. ***
(In reply to Germán Poo-Caamaño from comment #4) > The issue is how GIO builds a GFile, which is: > > static GFile * > new_for_cmdline_arg (const gchar *arg, > const gchar *cwd) > { > GFile *file; > char *filename; > > if (g_path_is_absolute (arg)) > return g_file_new_for_path (arg); > > if (has_valid_scheme (arg)) > return g_file_new_for_uri (arg); > > if (cwd == NULL) > { > char *current_dir; > > current_dir = g_get_current_dir (); > filename = g_build_filename (current_dir, arg, NULL); > g_free (current_dir); > } > else > filename = g_build_filename (cwd, arg, NULL); > > file = g_file_new_for_path (filename); > g_free (filename); > > return file; > } > > And has_valid_scheme() checks for valid scheme characters > and colon. So, it creates the file using g_file_new_for_uri(). > > To fix this issue, we would need to implement a helper that > checks the special case of 'file:' without '//', and call > g_build_filename() and g_file_new_for_path(). I guess that according to the definition of file uri scheme, the correct URI is file://host/path... So, file:withcolon.pdf should IMO be interpreted as a local file..
There is a bug already in Glib (bug 676626), and Gio is the place where this should be fixed. *** This bug has been marked as a duplicate of bug 676626 ***