GNOME Bugzilla – Bug 655194
gio.File ignores uri fragments on file:// URIs
Last modified: 2018-05-24 13:15:22 UTC
When using file:// URIs, URI fragements are silenetly dropped. For example: gio.File("file:///foo#fragment").get_uri() -> "file:///foo" whereas gio.File("sftp://localhost/foo#fragment").get_uri() -> "sftp://localhost/foo#fragment" This is inconsistent behavior, and leads to applications not being able to rely on fragments working correctly. file:///example.html#anchor should work just as well as http://example.com/example.html#anchor, but this bug prevents that.
This behavior depends on GVFS backend implementation. For file://, the fragment is dropped. Imho, it's arguable if the g_file_get_uri() should keep the fragment or not. I think applications shouldn't rely on fragment being kept around.
I'm having the same issue as in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638699 where the filename contains an unescaped number sign, but not as a fragment, instead as something like "file:///foo#bar.jpg" (in the middle of the filename). If the number sign is escaped as %23 it works just fine, but some applications, like Google Chrome, do not escape the number sign when they call exo-open on downloaded files. If this happens, the "fragment" gets stripped from the file, even though it is not actually a fragment. Would it be best to fix this issue here, like the Debian exo-open bug says, or add escaping in exo-open instead?
If I do "gvfs-open /tmp/a#.doc", it works fine. So this doesn't look like a glib bug.
("this" == comment 2, not the OP)
No, running that command works fine for me too, the issue comes when "file://" is before the file, so "gvfs-open file:///tmp/a#.doc" gives me this error, even when "/tmp/a#.doc" exists: gvfs-open: file:///tmp/a#.doc: error opening location: Error when getting information for file '/tmp/a': No such file or directory Regarding the Debian bug I linked to, it looks like exo-open adds "file://" in front of any file paths it is given, after escaping any special characters using "g_uri_escape_string (string, G_URI_RESERVED_CHARS_ALLOWED_IN_PATH, TRUE);", however "#" is not in the list of reserved characters, so it does not get escaped in any way and is instead passed directly to gio.
(In reply to Jason Perrin from comment #5) > No, running that command works fine for me too, the issue comes when > "file://" is before the file, so "gvfs-open file:///tmp/a#.doc" gives me > this error, even when "/tmp/a#.doc" exists: Right, because "file://tmp/a#.doc" isn't a URL that refers to a file named "/tmp/a#.doc", it's a URL that refers to a file named "/tmp/a". > Regarding the Debian bug I linked to, it looks like exo-open adds "file://" > in front of any file paths it is given, after escaping any special > characters using "g_uri_escape_string (string, > G_URI_RESERVED_CHARS_ALLOWED_IN_PATH, TRUE);", however "#" is not in the > list of reserved characters, so it does not get escaped in any way and is > instead passed directly to gio. It works for me: >>> GLib.uri_escape_string("/tmp/a#.doc", "!$&'()*+,;=:@/", True) '/tmp/a%23.doc' (G_URI_RESERVED_CHARS_ALLOWED_IN_PATH isn't available from Python because gobject-introspection doesn't recognize the way it's defined, but that's the correct value.) The "G_URI_RESERVED_CHARS_ALLOWED_IN_PATH" in that call is "reserved_chars_allowed"; ie, it's a list of characters that *don't* get escaped. Since "#" is not in the list, it is not allowed, and gets escaped. Maybe exo-open is doing something dumb like calling g_uri_escape_string() but then accidentally prepending "file://" to the original version instead of the escaped version?
Oh ok, thanks for the clarification, I misunderstood what was going on with both "file://" and with the escaped characters. I mean the constant even has "ALLOWED" in the name, so I should have thought about that one a bit more before commenting about it. Anyway, looks like it was libexo's issue of not doing a proper job escaping, which they have fixed by now. I was using an older packaged version (0.10.2-4), instead of the current version, but was looking at the current source that had the escaped version already, so I was confused. The bug report for exo's side of things is at https://bugzilla.xfce.org/show_bug.cgi?id=9912. Anyway, thank you for your time in answering my questions, and I think this bug can be closed now given that fragments in file:// URIs are ignored by design.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/428.