Thanks for your bug report!
I wonder whether there is any standard on whether $prefix/local (or
specifically, /usr/local?) should also be scanned. I couldn't find any /local
specs in the LSB.
Is using /usr/local as a target path for user installation really that common?

Sidenote: Relevant code is in libgnomevfs/gnome-vfs-method.c:init_path_list.

I filed this bug report because I am the author of a gnome-vfs module which
allows access to Psion palmtops.  My problem is this:

* gnome-vfs is installed as part of my system (debian package)
* I distribute my module as source code to be compiled and installed.
* The FHS says that software compiled and installed by the user should be
installed into /usr/local or /opt.  Therefore to comply with this, my module
should be installed there.
* gnome-vfs only searches in /usr/lib/gnome-vfs-2.0, so I am forced to install
my module into /usr, breaking the FHS.  Alternatively, I can try to hack
GNOME_VFS_MODULE_PATH, but then I'd need to get all users to set this up every
time they log in.

what about packaging it so it's installed to /usr ? :)

Created attachment 46188 [details] [review]
Proposed patch (against HEAD).

Even if this use-case may be a bit rare, many specs suggest to also respect
these local directory constructions, including the XDG base directory spec [1].
So after all, it could be a good idea to add this.
On the patch: We don't have to expose this variable to configure, right?  I
don't know any reason for overriding the GNOME_VFS_LOCAL_LIBDIR variable.

[1] http://freedesktop.org/Standards/basedir-spec

Additionally, after setting this variable to a path, each program complains (but works):

GNOME_VFS_MODULE_CONFIG_PATH=/usr/local/etc/gnome-vfs-2.0/modules:/etc/opt/gnome/gnome-vfs-2.0/modules GNOME_VFS_MODULE_PATH="/usr/local/lib/gnome-vfs-2.0/modules:/opt/gnome/lib/gnome-vfs-2.0/modules" gnomevfs-ls ftp://ftp.gnome.org/

(process:17447): libgnomevfs-WARNING **: Cannot load module `/usr/local/lib/gnome-vfs-2.0/modules/libftp.so' (/usr/local/lib/gnome-vfs-2.0/modules/libftp.so: cannot open shared object file: No such file or directory)
.               (Directory, x-directory/normal) size 8192       mode 0755
..              (Directory, x-directory/normal) size 8192       mode 0755
.temp-nikke             (Directory, x-directory/normal) size 8192       mode 0700
HEADER.html             (Regular, text/html)    size 1006       mode 0644
Public   [link: /pub ]  (Directory, x-directory/normal) size 8192       mode 0755
...

Created attachment 68940 [details] [review]
Proposed patch

Christian Kellner and I agreed that scanning /usr/local by default isn't neccessary because it is a rather uncommon setup.

The new attached patch will prevent GnomeVFS from bailing when a module could not be found in any of the module directories if it later could be found in another directory. The codepaths aren't too pretty, but without major reorganization we can't tell load_module whether it's acting on a module specified by an absolute or a relative path.

gnome-vfs has been deprecated and superseded by gio/gvfs since GNOME 2.22, hence mass-closing many of the gnome-vfs requests/bug reports. This means that gnome-vfs is NOT actively maintained anymore, however patches are still welcome.

If your reported issue is still valid for gio/gvfs, please feel free to file a bug report against glib/gio or gvfs.

@Bugzilla mail recipients: query for
      gnome-vfs-mass-close
to get rid of this notification noise all together.


General further information: http://en.wikipedia.org/wiki/GVFS 
Reasons behind this decision are listed at http://www.mail-archive.com/gnome-vfs-list@gnome.org/msg00899.html