+ while (msg_list_head) {
+ struct msg_list *ml = msg_list_head;
+ int n = write(msg_fd_out, ml->buf + written, ml->len - written);
+ if (n < 0) {
+ if (errno == EINTR)
+ continue;
+ if (errno != EWOULDBLOCK && errno != EAGAIN)
+ return -1;
+ if (!flush_it_all)
+ return 0;
+ FD_ZERO(&fds);
+ FD_SET(msg_fd_out, &fds);
+ tv.tv_sec = select_timeout;
+ tv.tv_usec = 0;
+ if (!select(msg_fd_out+1, NULL, &fds, NULL, &tv))
+ check_timeout();
+ } else if ((written += n) == ml->len) {
+ free(ml->buf);
+ msg_list_head = ml->next;
+ if (!msg_list_head)
+ msg_list_tail = NULL;
+ free(ml);
+ written = 0;
+ }
+ }
+ return 1;
+}
+
+int get_redo_num(int itemizing, enum logcode code)
+{
+ while (1) {
+ if (hlink_list.head)
+ check_for_finished_hlinks(itemizing, code);
+ if (redo_list.head)
+ break;
+ read_msg_fd();
+ }
+
+ return flist_ndx_pop(&redo_list);
+}
+
+int get_hlink_num(void)
+{
+ return flist_ndx_pop(&hlink_list);
+}
+
+/**
+ * When we're the receiver and we have a local --files-from list of names
+ * that needs to be sent over the socket to the sender, we have to do two
+ * things at the same time: send the sender a list of what files we're
+ * processing and read the incoming file+info list from the sender. We do
+ * this by augmenting the read_timeout() function to copy this data. It
+ * uses the io_filesfrom_buf to read a block of data from f_in (when it is
+ * ready, since it might be a pipe) and then blast it out f_out (when it
+ * is ready to receive more data).
+ */
+void io_set_filesfrom_fds(int f_in, int f_out)
+{
+ io_filesfrom_f_in = f_in;
+ io_filesfrom_f_out = f_out;
+ io_filesfrom_bp = io_filesfrom_buf;
+ io_filesfrom_lastchar = '\0';
+ io_filesfrom_buflen = 0;
+}
+
+/* It's almost always an error to get an EOF when we're trying to read from the
+ * network, because the protocol is (for the most part) self-terminating.
+ *
+ * There is one case for the receiver when it is at the end of the transfer
+ * (hanging around reading any keep-alive packets that might come its way): if
+ * the sender dies before the generator's kill-signal comes through, we can end
+ * up here needing to loop until the kill-signal arrives. In this situation,
+ * kluge_around_eof will be < 0.
+ *
+ * There is another case for older protocol versions (< 24) where the module
+ * listing was not terminated, so we must ignore an EOF error in that case and
+ * exit. In this situation, kluge_around_eof will be > 0. */
+static void whine_about_eof(int fd)
+{
+ if (kluge_around_eof && fd == sock_f_in) {
+ int i;
+ if (kluge_around_eof > 0)
+ exit_cleanup(0);
+ /* If we're still here after 10 seconds, exit with an error. */
+ for (i = 10*1000/20; i--; )
+ msleep(20);
+ }
+
+ rprintf(FERROR, RSYNC_NAME ": connection unexpectedly closed "
+ "(%.0f bytes received so far) [%s]\n",
+ (double)stats.total_read, who_am_i());
+
+ exit_cleanup(RERR_STREAMIO);
+}
+
+
+/**
+ * Read from a socket with I/O timeout. return the number of bytes
+ * read. If no bytes can be read then exit, never return a number <= 0.
+ *
+ * TODO: If the remote shell connection fails, then current versions
+ * actually report an "unexpected EOF" error here. Since it's a
+ * fairly common mistake to try to use rsh when ssh is required, we
+ * should trap that: if we fail to read any data at all, we should
+ * give a better explanation. We can tell whether the connection has
+ * started by looking e.g. at whether the remote version is known yet.
+ */
+static int read_timeout(int fd, char *buf, size_t len)
+{
+ int n, ret = 0;
+
+ io_flush(NORMAL_FLUSH);