Getting debug logs

1. Terminate all gvfs daemons and the client application you use (e.g. Nautilus) at first:

   pkill gvfs; pkill nautilus

   (Be careful, this step will terminate also your pending file operations.)

2. Start main daemon with enabled debug output:

   GVFS_DEBUG=1 $(find /usr/lib* -name gvfsd 2>/dev/null) --replace 2>&1 | tee gvfsd.log

   You can use additional environment variables in special cases, e.g.: GVFS_SMB_DEBUG=10 GVFS_DEBUG=1 $(find /usr/lib* -name gvfsd 2>/dev/null) --replace 2>&1 | tee gvfsd.log

3. Reproduce your problem.
4. Terminate gvfs daemons after that.

   pkill gvfs

   (GVfs will operate as usual after this step.)

5. You can attach gvfsd.log to a bug report.

Testing custom build

It is a bit cumbersome given the fact that GVfs consist of multiple D-Bus services, shared libraries, and GIO modules. There are several options with different pros and cons:

• If you want to test only some changes to some backend, the easiest way is to run the necessary bits manually. You can run just the modified backend as described in #Spawning_backends_manually section, or you can run the main daemon manually from the prefix as described in #Getting_debug_logs section. If you run the main daemon, it automatically uses backends from the prefix also. Unfortunately, volume monitors and client codes are still used from the system installation. This is not usually a problem if you haven't modified them. But still, you can start the requested monitor manually. If you have made also some changes in client codes you can point the GIO_MODULE_DIR environment variable to the directory, where the modified libgvfsdbus.so library is installed, or use another approach...

  (This may not work if you test different version than it is in system.)

• Modify the package for your distribution.

  (This requires packaging knowledge.)

• Install GVfs in system paths.

  (This conflicts with system packages.)

• Setup GNOME JHBuild session with custom D-Bus services dir, or use custom D-Bus config file to see services from the prefix.

  (This requires system knowledge, big amount of time and luck to build whole JHBuild moduleset.)

Spawning backends manually

Before spawning a backend manually, you have just to be sure that potential credentials are already saved in the keyring, otherwise the backend fails without prompting. You can do this e.g. over Nautilus thanks to "Remember password until you logout", or "Remember forever" options. You can also use environment variables mentioned in #Getting_debug_logs section.

Default options:

[type=TYPE] [user=USER] [host=HOST] [port=PORT] [prefix=PREFIX]

Some backends has custom options:

./gvfsd-afp [volume=VOLUME] ...
./gvfsd-dav [ssl=true|false] ...
./gvfsd-http uri=[URI]
./gvfsd-smb [domain=DOMAIN] [user=USER] server=[SERVER] [port=PORT] share=[SHARE]

Examples:

• ./gvfsd-dav ssl=true user=foo host=my.owndrive.com prefix=/remote.php/webdav 

  (This doesn't work for accounts configured over "Online Accounts".)

• ./gvfsd-google user=foo host=gmail.com

  (foo@gmail.com has to be configured over "Online Accounts".)

• ./gvfsd-http uri=https://google.com

• ./gvfsd-mtp host=[usb:002,009]

• ./gvfsd-sftp host=localhost user=foo