commit 0e6434139716a63ce99e84525aa63890a6244378
Author: Alexander Larsson <alexl@redhat.com>
Date:   2013-10-03

    Update for 1.18.2

M	NEWS

commit 33df4211825ad9ef36272a3e5cf987ea8f7cfe01
Author: Alexander Larsson <alexl@redhat.com>
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 <rosslagerwall@gmail.com>
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 <rosslagerwall@gmail.com>
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 <rosslagerwall@gmail.com>
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 <rosslagerwall@gmail.com>
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 <oholy@redhat.com>
Date:	2013-09-26

    Post release version bump

M	configure.ac