Commit e147e48f added missing mutex guards for job_sources, which may
unfortunately lead to deadlock because g_vfs_channel_force_close
synchronously calls g_vfs_job_source_closed which is also guarded by
the same mutex.

The deadlock reveals another bug which was in that code. The code
iterates over job_sources list, but g_vfs_job_source_closed removes
current element of the list, which leads to invalid reads and
potentially to segfaults also.

This patch tries to fix the both mentioned issues.

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

The device file checks were added by mistake and it is not clear whether
it can't have some side-effect. Let's remove them and use g_strcmp0 for
sysfs path comparison for sure...

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

UDev events for devices without ID_GPHOTO2 property are ignored.
Although ID_GPHOTO2 seems don't have to be set for device when removing
and thus the volume is not removed. Let's ignore ID_GPHOTO2 when removing.

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

UDev events for devices without ID_MTP_DEVICE property are ignored.
Although ID_MTP_DEVICE seems don't have to be set for device when removing
and thus the volume is not removed. Let's ignore ID_MTP_DEVICE when removing.

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

Use daemon->lock when accessing daemon->job_sources as on other places.
This might potentially help to fix some segfaults.

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

Uevents handler can be connected even if mount operation failed (e.g.
device is unplugged in the middle of mount operation). Backend is
consequently finalized, however, g_vfs_backend_force_unmount can be
still called from on_uevent in the meantime. This might cause segfaults
in certain cases.

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

The trash::orig-path attribute calucaltion expects that the trash
is only one dir (i.e. .Trash, .Trash-$UID) and it fails for relative
paths in case it is not (i.e. .Trash/$UID). Let's propagate the topdir
and fix relative path handling...

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

Philip Langdale authored Nov 10, 2017 and Ondrej Holy committed Mar 02, 2018

Up until very recently, the Android MTP driver did not do bounds checking
on reads past EOF, leading to undefined behaviour, which includes
hanging the transfer on some devices.

According to Google engineers, this is fixed in the kernels used by
the Pixel and Pixel 2 (and this has been verified in testing), but
that basically means that every other Android device in existence has
this bug, and is unlikely to ever be fixed.

So, we need to enforce POSIX semantics ourselves and truncate reads
past EOF. libmtp has implemented a check, but we should validate as
well so that we have working behaviour without requiring a libmtp
update.

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

Automatic shadow mount handling in some cases works currently only thanks
to the bug in g_daemon_file_prefix_matches implementation, which I am going
to fix. The problematic case is when activation_root is equal to mount_root
(e.g. Nextcloud integration). The bug in _prefix_matches causes that it
succeeds also if the paths are equal, but this is wrong as per the docs.
Let's use also g_file_equal when looking for shadow mounts in order to fix
this issue.

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

g_daemon_file_equal() always return FALSE for files with different
mount_prefix even though the files can be equal. It happen when comparing
two files from different origins, e.g. g_mount_get_root() and
g_file_new_for_uri(). Let's do the same which is done in _prefix_matches
and _get_relative_path in order to fix this issue.

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

g_daemon_file_get_relative_path() fails for files with different
mount_prefix and always return NULL. It happen when comparing two files
from different origins, e.g. g_mount_get_root() and g_file_new_for_uri().

On the other hand, g_daemon_file_prefix_matches() can succeed in cases,
where paths don't have the same prefixes, because it just compares
mount_prefix of a parent with a path of a descendant, but a path of the
parent is ignored.

The code concatenates mount_prefix with a path, so the comparison never
succeeds if mount_prefix is set, because mount_prefix is already part of
the path in GDaemonFile. Let's ignore mount_prefix when comparing and
always compare the paths, so we can significantly simplify the code.

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

Michael Terry authored Aug 12, 2017 and Ondrej Holy committed Aug 24, 2017

Fix an if condition that resulted in trying to strdup(0x1).

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

The channel socket pair is not set as nonblocking currently, which may cause
deadlocks in some cases (e.g. in-mount copy over read-write fallback), because
g_output_stream_write_async may block. This issue appears after increasing max
size of buffer in read channel:
https://bugzilla.gnome.org/show_bug.cgi?id=773826

Set channel sockets as nonblocking to be sure that _async methods don't block.

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

The afc daemon sometimes aborts on g_mutex_clear when force unmounting.
Leak the mutex in order to avoid the aborts. The daemon will hopefully
finish successfully then...

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

Colin Leroy-Mira authored Jul 21, 2017 and Ondrej Holy committed Jul 24, 2017

This patch fixes DAV stripping leading and trailing spaces from server
responses. This fixes access to DAV files and directories which names start or
end with a space.

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

Password-based authentication used for ownCloud/Nextcloud was broken
by GTask port (commit fdda2841). GTask is used as user_data for async
callbacks currently, however, user_data is incorrectly cast to MountOp
in this case. Use g_task_get_task_data in order to fix this issue.

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

If file cache is not loaded properly (e.g. because of cancellation),
it may lead to various problems (e.g. incomplete enumeration). Let's
return error in such case and rebuild the cache next time...

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

This reverts commit 1820d364.

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

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

Ligdata recently added API to obtain a real file size. Use
gdata_documents_entry_get_file_size if libgdata 0.17.7 is available
instead of gdata_documents_entry_get_quota_used, which returns 0
in some cases (e.g. shared files).

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

File handle may be NULL, so it has to be checked before dereferencing.

This issue was revealed by coverity scan.

Free may be called on statically allocated memory in case of parsing
error. Let's do not touch the output parameter at all in case of failure.

This issue was revealed by coverity scan.

Initialize pointers properly in order to avoid usage of unitialized,
or already freed memory.

This issues were revealed by coverity scan.

The result from strtol is stored in uid_t and then checked for
LONG_MAX and LONG_MIN, however, uid_t doesn't have to be long. Let's
check just the errno value, it should be enough.

This issue was revealed by coverity scan.

Commit 60f96c8b broke x-content-types setup, because is_media_player is
always FALSE. Let's introduce g_vfs_backend_set_x_content_types helper
and set x-content-types properly.

This issue was revealed by coverity scan.