GitLab

Daemons shouldn't be printing directly to stdout, but should be using
the normal GLib logging system. The messages output by this daemon
will not show by default, but setting `G_MESSAGES_DEBUG=GVFS-AFC` in
the environment will cause them to appear.

Remove unnecessary while loop since g_input_stream_read_all
and g_output_stream_write_all guarantee that all data is
read/written when exiting successfully.

Since we moved to fuse 3 big_writes are enabled by default.
There is no need to manually specify max_write anymore since the
set value is actually smaller than the libfuse default.
Let libfuse figure out the right value.

This increses the transfer speed from 31MiB/s to 43MiB/s between
my system and a SMB share.

The udisks id_type crypto_unknown is used for devices which are possibly
encrypted.

In udisks, this uncertainty is conveyed to the user by using the long name
"Possibly encrypted", and the short name "Encrypted?".

GVfs used to display all devices with id_usage == "crypto" as
"Encrypted". This commit instead uses the string "Possibly Encrypted" if
id_type == "crypto_unknown".

Earlier, we were deleting a directory irrespective of whether it
was empty or not. This would cause a permanent deletion of the
folder on Drive, and accidental deletions could be catastrophic.

`g_file_delete()` states that if a directory is supposed to be deleted,
the job should only carry forward to completion if the directory is
empty, else it should error out. We fix this behaviour of delete
operation in google backend by conforming to GIO's documentation.

Currently in delete operation, if the entry gets resolved but parent
resolution fails, the jump to `out` label (while handling error) will
cause the existing entry's ref_count to decrease by 1 (since `out`
label calls g_object_unref on entry).

We fix the issue by removing g_object_unref from `out` label and
suitably unreffing the entry.

Target executables used as monitors do not depend on `libgvfscommon`
or `libgvfsdaemon`, which are `gvfs` libraries installed outside of
the default library directory.

Due to this reason, they don't need to set `rpath` parameter.

On Slackware development branch with gvfs-1.40.2, I just noticed this:
  # ldd /usr/lib64/gvfs/libgvfsdaemon.so | grep "not found"
	libgvfscommon.so => not found

After some backtracking, it seems that this first occurred in the
switchover from autotools to meson in the 1.36.x --> 1.38.x bump.

Big thanks to Cogitri in #gnome/irc.gnome.org for the patience and
assistance with troubleshooting this.
Signed-off-by: Robby Workman <rworkman@slackware.com>

Currently, whenever we perform a rename operation, we set the `entry`'s
title to new display name, but at the time of removal of this entry from
cache, we still use the newer title. Hence, each time rename is done, a
single stale entry remains. This commit fixes the issue by reverting
back the title to the original display name of `entry` and then
performing a removal from cache.

Fixes: #410

In g_proxy_volume_monitor_register() we create a GVfsDBusDaemon object
(which is also of type GDBusProxy) but never free it. This causes there
to be a dangling reference to the singleton GDBusConnection object used
by the GDBusProxy for the rest of the lifetime of a process that uses a
gvfs function such as g_file_new_for_path(). With the recent changes I
made to GLib[1], that extra reference leads to a warning after a 30
second delay in g_test_dbus_down().

So this commit frees the GVfsDBusDaemon object after it has served its
purpose in g_proxy_volume_monitor_register(), which fixes the test
failure I'm seeing in another project.

This is consistent with how we handle GDBusProxy objects in most of the
rest of gvfs, but there are two places where they are leaked:
1. in g_proxy_volume_monitor_constructor(), but that object appears to
be intended to live forever, so it's unclear what should be done there
2. in meta_tree_get_metadata_proxy(), but there the proxy is a static
variable so it's unclear when it should be freed

If you try to reproduce this leak, note that if gio takes its "lazy
loading" code path in g_io_modules_scan_all_in_directory_with_scope(),
this g_proxy_volume_monitor_register() function may not be executed. So
I had to change an if condition so that we would always call
g_type_module_use(). That lazy loading only happened when I built and
installed gvfs myself rather than using the distribution's package.

[1] glib!963