Gnome un-aware file handling (was: UNDELETION EXT3 workaround)
awalton at gmail.com
Wed Feb 20 02:11:58 UTC 2008
On Feb 19, 2008 6:52 AM, Aurélien Naldi <aurelien.naldi at gmail.com> wrote:
> On Feb 19, 2008 12:35 PM, Markus Hitter <mah at jump-ing.de> wrote:
> > Am 19.02.2008 um 04:41 schrieb Jared Schlicht:
> > > The goal with desktop distros seems to be "The user should not have
> > > to touch
> > > the command line".
> > This might be a valid goal but doesn't work very often. Many, many
> > applications are not Gnome-aware and it's impossible for them to open
> > a file on a network drive, for example.
> > You have to copy the thing to a local drive with the file manager and
> > open the thing there. Alternatively, you can mount network shares in
> > the file system, but this requires touching the command line yet again.
> > I'd be glad hearing about a file manager actually mounting drives
> > instead of using voodoo, like Nautilus does.
> AFAIK, the upcoming version of nautilus does it thanks to the move
> from gnome-vfs to gio/gvfs . Anyway, when nautilus was first
> written, this was not possible as mounting a remote directory used to
> require admin rights, hence the need for a "user space mount" which
> was provided by gnome-vfs (and which is now available in a more
> generic way thanks to FUSE.
> I have not tested it yet though, but it is in hardy right now. The bad
> thing is that the new nautilus still contains some regressions
> compared to the previous one, let's hope this will be fixed in time
> for hardy :).
>  http://arstechnica.com/journals/linux.ars/2007/09/28/gnome-2-22-planning-gio-and-gvfs-proposed-for-inclusion
> Aurélien Naldi
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
I just want to add a tiny bit of clarification to this. GnomeVFS was
an ancient design (late 90s), written to solve the problem they had
then (we need apps to use URIs too??? Uh oh), and wasn't really
completely thought out at the time (the library's design spiraled into
what today is a pretty jumbled mess. I certainly can't follow it).
GIO/GVFS attempts to correct this problem by making the VFS a much
lower level in the stack and GVFS itself can be mounted via FUSE, so
that any non-GVFS aware app can still use locations mounted within
GVFS, they just need to use ~/.gvfs/. It's a tiny bit lame at the
moment as there is no way to reverse map ~/.gvfs/mysharepoint/ to,
say, smb://workgroup/mysharepoint/, but it's still functional for
non-GNOME applications (for KDE applications, someone is working on a
KIO-GIO component, so they will be able to use GVFS natively without
the FUSE mounter).
Using FUSE as a crutch for GVFS isn't a great idea though, as you
never know what the difference between the various virtual file system
backends may be, that you could determine if your program was well
coded to do so. So while your generic command line tools might work,
just as commonly they might not (for example, network:// doesn't
support file creation, so when you attempted to mv some file into it,
you'd get a really strange error and you'd scratch your head and play
around with it for a while before you realized "Oh, maybe that backend
doesn't support file creation").
More information about the Ubuntu-devel-discuss