metadata/metatree.c | 10 9 + 1 - 0 !
1 file changed, 9 insertions(+), 1 deletion(-)

 nuke the metadata file if magic blob is wrong

Related to https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/405432,
https://gitlab.gnome.org/GNOME/gvfs/-/issues/255,
https://gitlab.gnome.org/GNOME/gvfs/-/issues/122,
https://bugzilla.gnome.org/show_bug.cgi?id=750113,
https://bugzilla.gnome.org/show_bug.cgi?id=598561

TODO: This was never applied upstream, but it's unclear to me why it was
marked as obsolete -smcv

daemon/gvfschannel.c | 5 3 + 2 - 0 !
1 file changed, 3 insertions(+), 2 deletions(-)

 don't try to announce the finish of a null job.

TODO: It isn't clear whether this is still needed. According to a
2013-11-04 comment upstream: "This is not reproducible on current git
master so it must have been fixed up in the meantime."

client/gdaemonvfs.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 don't crash when creating volume monitors if the vfs was never
 initialized

daemon/gvfschannel.c | 5 3 + 2 - 0 !
daemon/gvfsdaemon.c | 7 5 + 2 - 0 !
2 files changed, 8 insertions(+), 4 deletions(-)

 make sure to keep a ref to jobs while they run in a thread

test/gvfs-test | 5 3 + 2 - 0 !
1 file changed, 3 insertions(+), 2 deletions(-)

 skip the umockdev test

The trace is out of date & needs to be re-recorded by somebody who has
the hardware.

test/gvfs-test | 6 3 + 3 - 0 !
1 file changed, 3 insertions(+), 3 deletions(-)

 gvfs-test: increase timeout to 10s

In normal operation some operations - particularly unmounting - can take
quite a while. Let's give things a bit longer before giving up.

Patch originally by Andreas Hasenack <andreas.hasenack@canonical.com>

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=794487
Bug: https://gitlab.gnome.org/GNOME/gvfs/-/issues/331
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1713098