Ross Lagerwall authored Oct 21, 2014 and Ondrej Holy committed Feb 02, 2015

Retrieve the username from the secret store rather than simply using the
default username with the retrieved password.  Without this, the backend
does not correctly recall the login details of a non-default user when
the username is not specified in the URI.

E.g. if my username is "ross" and I stored the login details for "john",
logging in with a URI of sftp://host/path should use john's details
rather than john's password with ross as a username.

If the username is specified directly, e.g. sftp://john@host/path, this
already did work correctly (and should continue to).

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

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

Ross Lagerwall authored Dec 20, 2014 and Ondrej Holy committed Jan 06, 2015

Without this, if the function fails, the error presented to the user looks
like:

GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code1:
Can't find metadata file /home/ross/.local/share/gvfs-metadata/home

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

It can fail when e.g. database file is corrupted or doesn't have
correct permissions. This patch also adds warnings to be possible
determine reason why initialization failed.

It is based on patches from Matthew W. S. Bell and Ross Lagerwall.

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

Ross Lagerwall authored Sep 28, 2014 and Ondrej Holy committed Dec 03, 2014

It is not possible to respond to unmount dialog after 2 sec timeout,
because the callback isn't set properly. The dialog reopens every 2
seconds until the daemon is killed.

Because a dbus method is called every 2 seconds, we may get multiple
replies (e.g. one normal reply and several error replies due to a closed
connection).  Handle this by ignoring all but the first reply.

Based on a patch by Ondrej Holy.

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

If the dialog about blocking processes was cancelled,
G_IO_ERROR_FAILED_HANDLED will be returned and backend
won't be unmounted.

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

When an application tries to save a larger key-value pair than the size
of the journal, it triggers the journal to be flushed to make space for
the entry and the operation is then retried, but it never fits, and the
loop continues forever.

This patch removes the endless retry loop and retries the operation
only once after the flush. We know that there isn't enough space for
the entry if it fails after the flush.

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

Antoine Jacoutot authored Jan 23, 2014 and Ondrej Holy committed Jan 23, 2014

When not using abstract sockets, gvfs tries to rmdir the socket
directory but it still contains the socket so the call fails.
We now make sure to remove the socket first.

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

Set an infinite timeout for responses to enumerate() otherwise it can
timeout when enumerating large, slow directories.

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

Previously, opening the root directory would generate an error and cause
the backend to abort:
    backend_dbus_handler org.gtk.vfs.Mount:OpenForRead
    Queued new job 0xba4350 (GVfsJobOpenForRead)

    ** (process:6778): CRITICAL **: g_vfs_afp_volume_open_fork_finish:
    assertion 'g_simple_async_result_is_valid (res, G_OBJECT (volume),
    g_vfs_afp_volume_open_fork)' failed

    (process:6778): GLib-CRITICAL **: g_error_copy: assertion 'error !=
    NULL' failed

Instead, remove the special-casing for the root directory since it is
handled correctly anyway.

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

When libarchive fails g_vfs_job_failed is called even as
g_vfs_job_succeeded which cause segfault. Set GError instead of
g_vfs_job_failed to fix that.

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

Opening data connections is a complex process and can fail in multiple
stages. Instead of requiring the code to close them manually and
throwing assertions when that doesn't work we just clean up after all
jobs automatically.

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

Philip Langdale authored Nov 30, 2013 and Ondrej Holy committed Dec 13, 2013

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

Handle a read after a seek past the end of the file by ignoring the
requested range not satisfiable http error (416) and simply returning 0.

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

Fix the SEEK_END offset calculation by reversing the sign of offset and
taking into account the offset of the previous seek.

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

Ensure that the range header is updated every time ensure_request() is
called in case it has been updated.

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

Previously, the dav backend would segfault when reading after a seek (or
also if you did a read_async() without an explicit send()/send_async()
first) because the stream from soup_request_send_finish() was not being
stored, so store it.

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

If an error occurs during mounting, don't explicitly release the device
because it is released anyway during finalize().

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

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

Philip Langdale authored Nov 24, 2013 and Ondrej Holy committed Nov 28, 2013

I've seen a ton of bug reports where the backend crashes due to
operations executing after an unmount begins. I think it's a
sufficient solution to check the unmount flag that we already have
and then immediately abort the operation.

Generally, this is only seen with operations that are initiated
implicitly like do_query_info or do_enumerate, but I've added the
protection to all operations for consistency.

In certain cases, reading the packet length may take more than one call.
Make this work by calculating the offset into the reply_size correctly.

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

If the daemon is killed during the fallback copy, it is possible that
proxy is NULL which causes a segfault when unrefing it.  Use
g_clear_object() instead.

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

If gvfs_archive_open fails, libarchive immediately calls
gvfs_archive_close which causes a crash due to calling g_object_unref on
the NULL stream.

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