| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Archive backend is stucked in endless loop currently e.g. if you try to
mount encrypted zip file. It is caused because ARCHIVE_FAILED error is
not handled, when reading data from the archive.
ARCHIVE_FAILED is handled with this patch. Mount job doesn't fail, just
because of unknown file size, but open_for_read job fails if
ARCHIVE_FAILED is returned.
https://bugzilla.gnome.org/show_bug.cgi?id=752366
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
libcdio 0.84 already returns UTF-8 data. Trying to interpret it
as ISO-8859-1 won't lead to pretty results, so we better stop
doing that.
https://bugzilla.gnome.org/show_bug.cgi?id=751389
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Unmount progress is shown only when unmount takes more then 1.5 seconds.
However the progress should be shown everytime when unmount is finished
for users to be sure it is safe to remove device.
https://bugzilla.gnome.org/show_bug.cgi?id=750267
|
|
|
|
|
|
|
|
| |
Copy the modification timestamp after copying a file from the device.
Normally, this would be done in the copy fallback path, but if pull() is
implemented, it must also copy metadata.
https://bugzilla.gnome.org/show_bug.cgi?id=749788
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Uri is altered before g_app_info_launch_default_for_uri, because of
the following code (from the commit 95aac17):
file = g_file_new_for_commandline_arg (location[i])
uri = g_file_get_uri (file);
Examples of uri changes:
mailto:email -> mailto:///email
ssh://user@host -> sftp://user@host/
This patch cause that uri isn't preprocessed for locations with scheme
(however absolute and relative paths are still preprocessed).
https://bugzilla.gnome.org/show_bug.cgi?id=738690
|
| |
|
|
|
|
|
|
|
|
|
| |
Get the storage information from the device in query_info() and
query_fs_info() so that the disk space numbers are correct. Previously,
if you deleted an item and checked the free space, it would not have
changed.
https://bugzilla.gnome.org/show_bug.cgi?id=749491
|
| |
|
| |
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=747221
|
|
|
|
|
|
| |
gvfsdbusutils.[ch] are renamed to gvfshalutils.[ch] to prevent confusion.
https://bugzilla.gnome.org/show_bug.cgi?id=722411
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This caused make to fail e.g. in libgweather:
(g-ir-compiler:11785): GVFS-RemoteVolumeMonitor-WARNING **: Error: The connection is closed
kernel: traps: g-ir-compiler[4216] trap int3 ip:7f76f9fa2663 sp:7fff1e6a2d90 error:0
With gvfs-1.22.3 no error's
https://bugzilla.gnome.org/show_bug.cgi?id=746398
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Use install-data-hook rather than install-data-local as
install-data-hook runs after the other install rules have run. This is
important for a parallel install so that the destination directory
already exists when the symlinks are created.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
g_simple_async_result_complete should only be used from the thread on
which the callback should be invoked. Also, the gvfs job threads do not
have their own GMainContexts which causes an assertion failure [1] when
invoking g_simple_async_result_complete. Instead, use
g_simple_async_result_complete_in_idle().
[1] (process:11772): GLib-CRITICAL **: g_main_context_push_thread_default: assertion 'acquired_context' failed
https://bugzilla.gnome.org/show_bug.cgi?id=629345
|
|
|
|
|
|
|
| |
Don't run a recursive main loop on a separate thread with a shared
GMainContext.
https://bugzilla.gnome.org/show_bug.cgi?id=629345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AvahiClient appears to require that avahi_service_resolver_new is
invoked from the same thread to which its poll function is bound
otherwise it can crash with a callback running while
avahi_service_resolver_new is still busy.
To fix this, always run avahi_service_resolver_new from the main loop.
To simplify the code, any errors from the function are ignored for now.
This crash could be reproduced 100% of the time by trying to mount
dav+sd (via gnome-user-share) in a single-CPU VM.
https://bugzilla.gnome.org/show_bug.cgi?id=629345
|
| |
|
| |
|
| |
|
| |
|
| |
|