GNOME Bugzilla – Bug 707796
Network file I/O (using an HTTP/HTTPS URI) returns "Operation not supported" due to missing gvfsd on Android
Last modified: 2013-10-08 15:30:44 UTC
Constructing a GFile with an HTTP/HTTPS URI using g_file_new_for_uri(), and then using g_file_read() on it fails with error == "Operation not supported" on Android. As far as I can tell, this is due to gvfsd missing on the Android platform. I can't see there being a workaround for it either, and so for now, network file I/O is completely broken on Android. The background for this bug-report is the following. I would like to add oVirt (http://www.ovirt.org) support for my SPICE (Red Hat remote desktop protocol, http://www.spice-space.org) client called aSPICE. The SPICE protocol implementation and oVirt support library (govirt, http://cgit.freedesktop.org/~teuf/govirt) uses glib, which is now much easier to compile on Android. However, govirt relies on reading files over the network, and after constructing an HTTPS URI for the file, it gives it to g_file_new_for_uri(), and then tries to load the contents with g_file_load_contents(), which uses g_file_read() in turn.
Use libsoup?
This isn't a bug. You're describing the way the system is supposed to work; glib's remote filesystem implementations are in the gvfs package. If you don't have gvfs installed, then glib only supports file: and resource: URIs, and everything else is not supported. (If for some reason using gvfs was impossible, you could write your own implementation of the GVfs gobject interface, and implement http and whatever other filesystem types you needed there.)
Hello! Thanks for your prompt answers. I've tried building gvfs on Android and find it impossible due to the following sequence of dependencies. There may be more, but this is what I was blocked by: glib network I/O -> gvfs -> libsoup-gnome -> gnome-keyring -> gcr-3 -> gcr-ui-3 -> GTK I still think it's a bug that glib's network I/O ends up depending on GTK. This makes it very hard to port and not very low-level at all. Can such an argument convince you?
the code to actually do the network I/O has to come from somewhere... if it wasn't in gvfs, then glib itself would be depending on these libraries. in this particular case, you could build libsoup with --disable-gnome (or build a newer version that doesn't depend on gnome-keyring anyway).
I understand that the code has to come from somewhere, i was onlybasking whether it makes sense for it to come from libraries that depend on GTK. I was building libsoup with the --disable-gnome flag, but gvfs has no such option and has an unconditional dependency on libsoup-gnome... Perhaps the fault lies with gvfs, then, correct?
If you are using the latest stable or unstable version of gvfs, there is no reason for it to be requiring libsoup-gnome (since everything in libsoup-gnome is deprecated) and so that would be a bug in gvfs if it did. However, the latest version of libsoup doesn't require gnome-keyring either, so probably you're not building the latest versions of things.
Hi Dan, I am using the latest unstable version of gvfs. I am configuring it thus: ./configure --prefix="${TARGET_PREFIX}" \ --host=arm-linux-androideabi \ --enable-static \ --disable-shared \ --disable-gphoto2 \ --disable-udev \ --disable-gudev \ --disable-gtk Almost the only thing I'm not disabling is the http/dav backend, which is what I'm interested in. When I cross-compile it, the process gets to the following step: CCLD gvfsd-http /home/iordan/software/android-ndk-toolchain/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld: error: cannot find -lsoup-gnome-2.4 It is unable to find -lsoup-gnome2.4, which is why I assumed that I must build libsoup-gnome-2.4 and got into the dependency mess which eventually required GTK. Thanks! iordan
Hello again, would you like me to open a separate bug against gvfs? Thanks! iordan
sure, feel free to file a bug against gvfs
Dear GNOME devs, You've closed this bug, but I would like to make you aware of the awkwardness and limitations of the current glib-networking implementation. I noticed that glib-networking does not operate properly when the app which uses it is run over SSH X11 tunnelling and in a NX session. It would most probably behave the same in a Xvfb session too. Gigolo shows only "Unix Device (file)" as a supported protocol when run over SSH and in NX. Moreover, trying to read from a file over the network returns the familiar "Operation not supported" error. It seems that this is expected behaviour given the gvfsd requirement. I'm sending this in the hopes that you would consider a change in the implementation. This would make glib as a whole much more portable on platforms where dbus and gvfsd are not available. Please tell me what you think! Sincerely, iordan iordanov