Re: Plans for gnome-vfs replacement
- From: Federico Mena Quintero <federico ximian com>
- To: Alexander Larsson <alexl redhat com>
- Cc: "gnome-vfs-list gnome org" <gnome-vfs-list gnome org>, "gtk-devel-list gnome org" <gtk-devel-list gnome org>
- Subject: Re: Plans for gnome-vfs replacement
- Date: Wed, 20 Sep 2006 10:41:12 -0500
On Tue, 2006-09-19 at 14:54 +0200, Alexander Larsson wrote:
> > s/TRUE/FALSE/, I think. (gnome_vfs_uri_is_local() used to say that NFS
> > filesystems were local, now it says they're not.) Are you suggesting
> > that this behavior is going to go away? It's useful in places as a
> > heuristic, even if it's not 100% reliable. (Although obviously it's only
> > useful if it's guaranteed to not hang.)
>
> Oh, yeah FALSE. I'm not really suggesting anything in particular here.
> Just describing a problem. Its true that there are cases where you want
> to know whethe a file is network mounted or not, but almost all cases
> that were using gnome_vfs_uri_is_local() meant it to check for a
> file:/// uri. The fact that it changed behaviour meant a lot of places
> suddenly broke on NFS shares, and were made a lot slower (since it
> suddenly is a call that does i/o). I've personally changed a lot of code
> to do a g_str_has_prefix("file://") in lots of places.
Both Nautilus and the file chooser seem to use is_local() for just two
things:
1. "If I strip the method prefix, can I feed the filename to POSIX
calls?". This problem goes nicely away when we switch to FUSE.
2. "Will a stat() or open() be slow on this file?". This works
reasonably well. The only problem is that file-method.c implements it
as a blacklist of known-to-be-remote file systems, *not* as a whitelist
of known-to-be-local ones. So occasionally we get bug reports like "I
have a foofs mount which is slow", where foofs is an obscure network
file system like Novell's novfs.
A bigger problem is that is_local() blocks very badly if you run it on a
file which is on a stale NFS mount, because it stat()s the file directly
to get at its st_dev and such. I *think* this could be better
implemented by stat()ing each component from the root down to the actual
file, and stopping whenever we get to a directory which is a nonlocal
mount. [Of course, stat()ing recursively sucks, but what can you do.]
This problem about blocking on stale mounts shows up in the file
chooser. We do is_local() on each bookmark to see whether to show it or
not, depending on whether the file chooser is configured to show
local-only files. If you have an NFS bookmark and the mount is stale,
it hangs.
Also, the calling code could be smarter about not running is_local() for
every single file... maybe we can assume that if a directory is local,
then every file under it is also local (but not subdirectories, which
may be mounts).
Federico
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]