commit 0e6434139716a63ce99e84525aa63890a6244378 Author: Alexander Larsson Date: 2013-10-03 Update for 1.18.2 M NEWS commit 33df4211825ad9ef36272a3e5cf987ea8f7cfe01 Author: Alexander Larsson Date: 2013-10-03 client: Don't user g_source_remove() on non-default main context We created a GSource, attached it to a non-default main context and then removed it via g_source_remove, which removed the source with the same id on the main context, which typically was the X fd, causing everything to stop working! Non-default main contexts must use g_source_destroy() https://bugzilla.gnome.org/show_bug.cgi?id=708744 M client/gdaemonfileenumerator.c commit 50e927218909b87bce5bc792621b7db8c47538fc Author: Ross Lagerwall Date: 2013-09-25 fuse: Make file nonseekable if it actually is Instead of failing in read() with ENOTSUPP after the lseek on a nonseekable stream succeeds, make the lseek fail with ESPIPE, as it should. This is important for applications which test the return value of lseek to determine if the file descriptor is seekable. M client/gvfsfusedaemon.c commit 3e8cc556fe13a32518ebdd4c11a11f0006083844 Author: Ross Lagerwall Date: 2013-09-25 fuse: Enforce sync_read When running multithreaded, fuse can issue readahead requests out of order which can cause subsequent reads to fail with ENOTSUPP (if seeking backward is not supported on the stream). Force readahead to occur in order to prevent this problem. M client/gvfsfusedaemon.c commit 64ccbde184653f2ce3ed3e5395eb336b379e5847 Author: Ross Lagerwall Date: 2013-09-25 fuse: Fix seek offset calculation Since fh->pos is already incremented by n_bytes_skipped, check if offset == fh->pos. This error was hidden by the fact that the operation is retried when -EIO is returned. When it was retried, the stream was already in the correct position and so no seek operation was required. M client/gvfsfusedaemon.c commit bdc3babbe21e5fed06876db4d56d1b13915fe1cb Author: Ross Lagerwall Date: 2013-09-21 daemon: Emit signal before returning dbus value In gvfsjobopenforread.c, the dbus method returns a value in create_reply which eventually results in a GVfsJobRead job to be sent to the backend. This could happen before the "new-source" signal is emitted. If this happens, the job is not queued because the "new_job" signal would not have been connected to a job source yet. The read then hangs because the GVfsJobRead is lost. This is hit often when performing large smb transfers (see https://bugzilla.gnome.org/show_bug.cgi?id=697782 and https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1075923). It can be reproduced by putting a small sleep before the g_signal_emit_by_name call. Fix this by emitting the "new-source" signal *before* the dbus method value is returned. This ensures that the "new_job" signal is set up before any further jobs are sent. Note that the same problem and solution applies for gvfsjobopenforwrite.c. M daemon/gvfsjobopenforread.c M daemon/gvfsjobopenforwrite.c commit a1dd98ffa979441a0b9db3289287eaeab2c1aadf Author: Ondrej Holy Date: 2013-09-26 Post release version bump M configure.ac