summaryrefslogtreecommitdiffstats
path: root/src/proto.c
diff options
context:
space:
mode:
authorRichard W.M. Jones <rjones@redhat.com>2011-03-18 18:27:21 +0000
committerRichard W.M. Jones <rjones@redhat.com>2011-03-18 18:27:24 +0000
commitf4d996fd26762053d68f46de5790aae893f03d38 (patch)
tree503049720d83e3d115afe55e5e04b5abd57a0939 /src/proto.c
parent33b638109ed66ea360b53b80b1f407b3a5f5ec39 (diff)
downloadlibguestfs-f4d996fd26762053d68f46de5790aae893f03d38.tar.gz
libguestfs-f4d996fd26762053d68f46de5790aae893f03d38.tar.xz
libguestfs-f4d996fd26762053d68f46de5790aae893f03d38.zip
proto: Fix both-ends-cancel case.
In the case where both ends cancel at the same time (eg. both ends realize there are errors before or during the transfer), previously we skipped sending back an error from the daemon, on the spurious basis that the library would not need it (the library is cancelling because of its own error). However this is wrong: we should always send back an error message from the daemon in order to preserve synchronization of the protocol. A simple test case is: $ guestfish -N fs -m /dev/sda1 upload nosuchfile / libguestfs: error: open: nosuchfile: No such file or directory libguestfs: error: unexpected procedure number (66/282) (Notice two things: there are errors at both ends, and the loss of synchronization). After applying this commit, the loss of synchronization does not occur and we just see the library error: $ guestfish -N fs -m /dev/sda1 upload nosuchfile / libguestfs: error: open: nosuchfile: No such file or directory The choice of displaying the library or the daemon error is fairly arbitrary in this case -- it would be valid to display either or even to combine them into one error. Displaying the library error only makes the code considerably simpler. This commit also (re-)enables a test for this case.
Diffstat (limited to 'src/proto.c')
-rw-r--r--src/proto.c31
1 files changed, 28 insertions, 3 deletions
diff --git a/src/proto.c b/src/proto.c
index 2ca24c29..cda731e5 100644
--- a/src/proto.c
+++ b/src/proto.c
@@ -848,9 +848,6 @@ guestfs___send_file (guestfs_h *g, const char *filename)
if (fd == -1) {
perrorf (g, "open: %s", filename);
send_file_cancellation (g);
- /* Daemon sees cancellation and won't reply, so caller can
- * just return here.
- */
return -1;
}
@@ -1034,6 +1031,34 @@ guestfs___recv (guestfs_h *g, const char *fn,
return 0;
}
+/* Same as guestfs___recv, but it discards the reply message. */
+int
+guestfs___recv_discard (guestfs_h *g, const char *fn)
+{
+ void *buf;
+ uint32_t size;
+ int r;
+
+ again:
+ r = guestfs___recv_from_daemon (g, &size, &buf);
+ if (r == -1)
+ return -1;
+
+ /* This can happen if a cancellation happens right at the end
+ * of us sending a FileIn parameter to the daemon. Discard. The
+ * daemon should send us an error message next.
+ */
+ if (size == GUESTFS_CANCEL_FLAG)
+ goto again;
+
+ if (size == GUESTFS_LAUNCH_FLAG) {
+ error (g, "%s: received unexpected launch flag from daemon when expecting reply", fn);
+ return -1;
+ }
+
+ return 0;
+}
+
/* Receive a file. */
/* Returns -1 = error, 0 = EOF, > 0 = more data */