| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GVfs calls gvfs_dbus_daemon_proxy_new() in cancelled signal handler which
internally needs CONNECTION_LOCK(connection). The lock can be unfortunately
held by gdbus worker thread which can call g_cancellable_disconnect(). This
obviously leads to deadlocks. I don't see any reason why we have to block
g_cancellable_disconnect() because of gvfs_dbus_daemon_proxy_new() resp.
gvfs_dbus_daemon_call_cancel(). Let's call it over idle source to not block
the cancelled signal handler in order to prevent the deadlocks.
It would be better to fix this issue directly in gdbus codes, however, it
is not fully clear to me, what is a proper way to fix this.
https://gitlab.gnome.org/GNOME/glib/issues/1023
(cherry picked from commit a1e85edaa95d5f69c1aa4a883fb1d308e2ad8a3a)
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This reverts commit 1a38caf8bcb4e02b68f8062319ef7736796a7e64.
|
| | |
|
| |
|
|
|
| |
The devel_utils and man meson options are by default false. Let's set
them to true to verify that everything is fine.
|
| |
|
|
|
| |
GitLab CI fails with GLib master currently because of new deprecated symbols.
Let's do not treat deprecated-declarations as error to fix CI for now.
|
| |
|
|
|
|
| |
Docker uses TLS by default now which breaks the runner. Let's disable TLS
for now to fix the update-image job. See the GitLab issue for more info:
https://gitlab.com/gitlab-org/gitlab-runner/issues/4501
|
| |
|
|
|
|
| |
The update-image job doesn't work as expected on forks, because the
$CI_REGISTRY_ variables are not properly set. Let's limit this only
to GNOME namespace to make it obvious.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The recent commit e9653aa9, which allows mounting when 403 is returned
instead of 401, broke the backend for the case when authentication
succeeded for subdirectory and 403 is returned for the parent folder.
The backend doesn't work properly, even though it doesn't return any
error from the mount operation. Nautilus just shows "File is of unknown
type" and the backend prints errors like "soup_auth_authenticate:
assertion 'password != NULL' failed". Let's prevent usage of the
workaround from commit e9653aa9 after the first successful auth to fix
this issue.
Fixes: https://gitlab.gnome.org/GNOME/gvfs/issues/417
|
| | |
|
| |
|
|
|
| |
Reflect the changes made in GNOME/gnome-build-meta!363 to make the job
work again.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
