GNOME Bugzilla – Bug 627491
g_file_resolve_relative_path() fails to resolve some relative paths
Last modified: 2018-05-24 12:41:13 UTC
Created attachment 168403 [details] gfile-resolve.c Suppose to have two files: /usr/lib64/browser-plugins/opensc-signer.so -> ../opensc-signer.so links to /usr/lib64/opensc-signer.so, which is a file /usr/lib64/browser-plugins/npwrapper.so -> ../../lib/nspluginwrapper/x86_64/linux/npwrapper.so links to /usr/lib/nspluginwrapper/x86_64/linux/npwrapper.so, which is a file Running attached trivial testcase, I see: resolving /usr/lib64/browser-plugins/opensc-signer.so link=../opensc-signer.so resolved=/usr/lib64/browser-plugins/opensc-signer.so resolving /usr/lib64/browser-plugins/npwrapper.so link=../../lib/nspluginwrapper/x86_64/linux/npwrapper.so resolved=/usr/lib64/lib/nspluginwrapper/x86_64/linux/npwrapper.so In the first case, the relative path is apparently resolved incorrectly. Marking bug as Critical. This problem causes freeze of epiphany web browser whenever opensc package is installed (smart card signer). The hang appears in webkit-1.2.0/WebCore/plugins/gtk/PluginPackageGtk.cpp PluginPackage::load() (while (g_file_test(finalPath.get(), G_FILE_TEST_IS_SYMLINK))...) Off-topic note: The need of g_type_init () before being able to use any GFile function is completely missing in the documentation and causes crash:
+ Trace 223326
The second expansion is incorrect as well - /usr/lib64/lib instead of /usr/lib. It seems that does not work properly for GFile that are not directory.
It'll work if you insert a g_file_get_parent at the right spot. A relative path needs to be resolved relative to the directory.
Created attachment 168812 [details] gfile-resolve-dir.c But documentation of g_file_resolve_relative_path() does not tell that it works only on directories (and webkit uses it on files). Modified code that calls g_file_get_parent() works properly: resolving /usr/lib64/browser-plugins/opensc-signer.so parent=/usr/lib64/browser-plugins link=../opensc-signer.so resolved=/usr/lib64/opensc-signer.so resolving /usr/lib64/browser-plugins/npwrapper.so parent=/usr/lib64/browser-plugins link=../../lib/nspluginwrapper/x86_64/linux/npwrapper.so resolved=/usr/lib/nspluginwrapper/x86_64/linux/npwrapper.so Reporting also as https://bugs.webkit.org/show_bug.cgi?id=44683 Documentation (Off-topic note in comment 0) fix reported as Documentation (Off-topic note in comment 0) fix reported as bug 628041
More generally, this is because resolve_relative_path always treats the last component of the base path as a directory. (Or, at least, some GFile implementations do, e.g. GLocalFile just calls g_build_filename.) So, for example: parent=file:///home/shaunm/index.html link=foo.html resolved=file:///home/shaunm/index.html/foo.html I think GIO should follow RFC 3986, section 5.2.3: http://www.ietf.org/rfc/rfc3986.txt Basically, strip everything after the trailing slash of the path component of the base URI.
s/trailing/last/
The documentation for g_file_relative_path() is not clear beyond a doubt on what the function does but I'd assume from reading it that it will work properly for the case that the GFile in question is a directory, even if I don't affix the trailing "/". Making the requested change would break that, along with any existing users. I'm fairly sure we can't do this. I think that Shaun's proposal for dealing with URIs which are more careful about including trailing "/" in the case of a directory may be interesting as a new API addition (assuming he's still interested).
Well, it's something that's handled by the backend, and there's no guarantee that different backends will do the same thing. So if you rely on that as an app developer, you're not really safe. That said, I'm pretty sure there are apps out there that do rely on the current behavior. Breaking them is probably not the best idea. At the moment, I have my own relative URI resolving code, so it's not blocking anything for me. But I do think it's something that's worth doing better in GLib.
Patch welcome :) As with all of the other operations, obviously the backend has to support it correctly -- if it doesn't, then it's the backend that has the bug.
-- 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/334.