1 files changed, 87 insertions, 0 deletions
diff --git a/gnome-base/gvfs/files/gvfs-1.16.3-emit-signal.patch b/gnome-base/gvfs/files/gvfs-1.16.3-emit-signal.patch
new file mode 100644
index 000000000000..6f8deb321456
--- /dev/null
+++ b/gnome-base/gvfs/files/gvfs-1.16.3-emit-signal.patch
@@ -0,0 +1,87 @@
+From bdc3babbe21e5fed06876db4d56d1b13915fe1cb Mon Sep 17 00:00:00 2001
+From: Ross Lagerwall <rosslagerwall@gmail.com>
+Date: Sat, 21 Sep 2013 20:22:27 +0000
+Subject: 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.
+---
+diff --git a/daemon/gvfsjobopenforread.c b/daemon/gvfsjobopenforread.c
+index d978136..41b5f34 100644
+--- a/daemon/gvfsjobopenforread.c
++++ b/daemon/gvfsjobopenforread.c
+@@ -194,6 +194,12 @@ create_reply (GVfsJob *job,
+       g_error_free (error);
+     }
+ 
++  g_vfs_channel_set_backend_handle (G_VFS_CHANNEL (channel), open_job->backend_handle);
++  open_job->backend_handle = NULL;
++  open_job->read_channel = channel;
++
++  g_signal_emit_by_name (job, "new-source", channel);
++
+   if (open_job->read_icon)
+     gvfs_dbus_mount_complete_open_icon_for_read (object, invocation,
+                                                  fd_list, g_variant_new_handle (fd_id),
+@@ -206,12 +212,6 @@ create_reply (GVfsJob *job,
+   /* FIXME: this could cause issues as long as fd_list closes all its fd's when it's finalized */
+   close (remote_fd);
+   g_object_unref (fd_list);
+-  
+-  g_vfs_channel_set_backend_handle (G_VFS_CHANNEL (channel), open_job->backend_handle);
+-  open_job->backend_handle = NULL;
+-  open_job->read_channel = channel;
+-
+-  g_signal_emit_by_name (job, "new-source", open_job->read_channel);
+ }
+ 
+ static void
+diff --git a/daemon/gvfsjobopenforwrite.c b/daemon/gvfsjobopenforwrite.c
+index a63e9cd..429e267 100644
+--- a/daemon/gvfsjobopenforwrite.c
++++ b/daemon/gvfsjobopenforwrite.c
+@@ -278,6 +278,12 @@ create_reply (GVfsJob *job,
+       g_error_free (error);
+     }
+ 
++  g_vfs_channel_set_backend_handle (G_VFS_CHANNEL (channel), open_job->backend_handle);
++  open_job->backend_handle = NULL;
++  open_job->write_channel = channel;
++
++  g_signal_emit_by_name (job, "new-source", open_job->write_channel);
++
+   gvfs_dbus_mount_complete_open_for_write (object, invocation,
+                                            fd_list, g_variant_new_handle (fd_id),
+                                            open_job->can_seek,
+@@ -285,12 +291,6 @@ create_reply (GVfsJob *job,
+   
+   close (remote_fd);
+   g_object_unref (fd_list);
+-
+-  g_vfs_channel_set_backend_handle (G_VFS_CHANNEL (channel), open_job->backend_handle);
+-  open_job->backend_handle = NULL;
+-  open_job->write_channel = channel;
+-
+-  g_signal_emit_by_name (job, "new-source", open_job->write_channel);
+ }
+ 
+ static void
+--
+cgit v0.9.2