We should finish constructing the innards of the object and not leave
it in an inconsistent state when we hit an error. The other option
would be to litter the rest of the code with NULL checks, but that
would be ugly and prone to errors.

We should also ensure that the reference counting stays consistent with
the non-error paths.

https://bugzilla.gnome.org/show_bug.cgi?id=755805

Accesses to the drives, volumes and mounts hash tables should be
guarded by the proxy_vm mutex.

https://bugzilla.gnome.org/show_bug.cgi?id=755805

Currently it is possible for the unmount op reply and the retry unmount
timer to race. A udisks2 unmount operation (or umount spawned command)
is started via the timer. In the meantime, a "cancel" or "force unmount"
reply is received which completes the gvfs unmount operation and frees
the private data. When the udisks2 unmount operation started by the
timer completes, it tries to use the freed data and segfaults.

To fix this, prevent starting an unmount operation when another is
already in progress.  If a timer callback is received while an unmount
operation is in progress, simply ignore it.  If an unmount op reply is
received while an unmount operation is in progress, store the result of
the reply and handle it once the unmount operation has completed.

https://bugzilla.gnome.org/show_bug.cgi?id=678555

secret_password_clear_finish() returns whether any passwords are
removed, so it may return FALSE without setting error. Handle this
properly (in this case all we care about is that there wasn't an error).

https://bugzilla.gnome.org/show_bug.cgi?id=751038

When GvfsBackendAfc is finalized, if we have a pending idle for a force
unmount, we need to remove it as by the time it runs, the GvfsBackendAfc
it's acting on will no longer be valid.

This fixes https://bugzilla.gnome.org/show_bug.cgi?id=751537 which can
be reproduced by plugging an iDevice, unmounting it in Nautilus, and
quickly unplugging it right after clicking on the eject icon.

g_steal_pointer was introduced in glib-2.44, however glib-2.42 belongs
to gnome-3-14 branch. Remove g_steal_pointer from gvfs-open to avoid
undefined reference build error.

Ray Strode authored May 20, 2015 and Ondrej Holy committed Jun 09, 2015

If gvfs-open exits before the program it starts fully activates, then
the dbus-daemon may avoid doing the activating method call.

This commit works around the problem by pinging the activated application,
and waiting for a reply.

https://bugzilla.gnome.org/show_bug.cgi?id=746534

If a job is waiting for a connection in
g_vfs_ftp_task_acquire_connection and the backend is force unmounted,
the queue is freed, and the function neither gets a connection nor
sets an error message which causes an issue later.

To fix this, set an error message if the queue is freed.

https://bugzilla.gnome.org/show_bug.cgi?id=653042

When unplugging an afc device without unmounting it first, the
corresponding gvfsd-afc process does not go away in spite of the
exit(1) workaround added for bgo#708288.

This happens because idevice_event_unsubscribe() in called from the
thread where the _idevice_event_cb() runs in. libimobiledevice (through
libusbmuxd) creates a thread to watch for device events, and calls the
idevice_event_cb_t from that thread. idevice_event_unsubscribe() then
forcfully kills that thread (see usbmuxd_unsubscribe() in libusbmuxd),
so exit(1) code after the call to idevice_event_unsubscribe() never gets
a chance to run.

Moving the call to idevice_event_unsubscribe() and the
g_vfs_backend_force_unmount() call to run in the main loop through
g_idle_add() avoids this issue, and allows the code handling force
unmounts to run as expected.

Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=708288

Fix from upstream:
http://hg.mozilla.org/mozilla-central/rev/e10a2ca070e6
https://bugzilla.mozilla.org/show_bug.cgi?id=1061898

https://bugzilla.gnome.org/show_bug.cgi?id=601583

Fix from upstream:
http://hg.mozilla.org/mozilla-central/rev/2c21b94a7775
https://bugzilla.mozilla.org/show_bug.cgi?id=961346

https://bugzilla.gnome.org/show_bug.cgi?id=601583

Synced from upstream commit:
http://hg.mozilla.org/mozilla-central/rev/f4157e8c4107
https://bugzilla.mozilla.org/show_bug.cgi?id=716478

https://bugzilla.gnome.org/show_bug.cgi?id=601583

Fix from upstream:
http://hg.mozilla.org/mozilla-central/rev/b623418ab1de
https://bugzilla.mozilla.org/show_bug.cgi?id=543805

https://bugzilla.gnome.org/show_bug.cgi?id=601583

Commit c15ec62 introduced exit for G_IO_ERROR_CLOSED, however we
should check also for G_IO_ERROR_CONNECTION_CLOSED. Unfortunatelly
this error code was introduced in newer version of GLib then available,
therefore use g_warning instead of g_error to avoid abrt reports.

https://bugzilla.gnome.org/show_bug.cgi?id=710490

Mount tracker skeleton is registered by name_acquired_handler
currently, however it is too late. Therefore e.g. mount operation
could fail for the first time with the following error:
No such interface `org.gtk.vfs.MountTracker' on object at path
/org/gtk/vfs/mounttracker

https://bugzilla.gnome.org/show_bug.cgi?id=743653

Exporting the skeleton after acquiring the name is racy, as documented
in the GIO docs for g_bus_own_name.

https://bugzilla.gnome.org/show_bug.cgi?id=743653

bash-completion has new completion loading code since version 1.90. The
completion files are loaded on demand, with ${completionsdir}/${command}
being sourced when a matching command is typed. This requires the
completion files to be named for all commands.

https://bugzilla.gnome.org/show_bug.cgi?id=738369

https://bugzilla.gnome.org/show_bug.cgi?id=738369

The function isn't returned after g_vfs_job_failed_literal, therefore
g_vfs_job_succeeded is executed and it fails on assert.

https://bugzilla.gnome.org/show_bug.cgi?id=743580

path_equal tries to unescape path before comparing. Unfortunately
this function is used also for already unescaped paths. Therefore
unescaping can fail. This commit reverts changes which was done in
commit 50af53da and unescape just uris, which aren't unescaped yet.

https://bugzilla.gnome.org/show_bug.cgi?id=743298