This damn implementation has been one of the biggest thorns in my side. It seems that the developer has no misunderstanding about its shortcomings either. He best puts in in his email to the gnome-vfs list:
The first, and most often discussed problem is of course compatibility. The various desktops use different vfs implementations, so they can’t read each others files. Many applications use no VFS at all and have no way to access files on vfs shares. And the existence of multiple vfs implementations makes it unlikely that they will start using one.
Basically, applications that want to access something remotely have to explicitly have built in compatibility for this gnome-vfs library. Windows, for example, can mount a samba share as drive letter “F:”, and an application like Notepad that want to interact with these files can without ever knowing that the file isn’t locally stored. Gnome’s use of gnome-vfs means that I can mount a samba share like “My Pictures” on my wifes computer, and Google’s Picasa has no way of seeing this mount point. Yuck! Clearly, the Windows implementation does this better at the moment. Actually, I would gather that Linux does it better, but just mounting the remote file system into its own, but this requires some typing in the terminal. Apple OS X I assume uses this approach, so is probably the best solution as I am sure it is easy.
Its also ungodly slow, as the authentication is not shared by each application accessing the resource. This means when Nautilus thumbnails images and movies, it has to reconnect to the resource each time it wants to generate a thumbnail. It can take several minutes to thumbnail maybe 50 files.
Parts of the new proposal are listed below:
I’d like to propose using a stateful model, where you have to explicitly initiate a session (“mount” a share) before you can start accessing files. This will give a well specified time when all forms of authentication will happen, when applications expect it and when they can use a more expressive and suitable API for this kind of operation. The actual i/o operations will then never cause any sort of authentication issues, and can thus be purely non-graphical (i.e. glib-only apps can do i/o). I imagine all/most actual mounting of shares will happen in the file manager and the file selector, or at gnome-session startup, so applications don’t really need to handle this themselves.
Not only is the model stateful. I’d like all state to be session global. That is, all mounts and network connections are shared between
all applications in the session. So, if you pass a file reference from one app to another there is no need to log in again or anything like that. I think this is what users expect.
Furthermore, if FUSE is supported on the system we can write a FUSE filesystem so that we can access the files as $HOME/.network/XXX. This can be made extra nice if the application (like e.g. acrobat) uses the gtk+ file selector but not the vfs by having the file selector detect a filename like this and reverse-mapping it into a vfs pathname and use the vfs for folder access.
Early benchmarks from Et tu, Cthulhu look promising:
In my particular setup, creating a file on a remote SMB share, filling it with 50MB data and reading it back took 16% longer using GVFS calls compared to bare POSIX and a kernel mount, and about twice as much CPU.
Congratulations to Alexander Larsson for being the best kind of maintainer – one that is not afraid to admit the shortcomings of his code and be open to extreme change. I look forward to seeing this come to life.
Zone of Mr. Frosti 