We recently experienced a rsync failure: inflate returned -3 (0 bytes) rsync error: error in rsync protocol data stream (code 12) at token.c(557) [receiver=3.1.0] rsync: connection unexpectedly closed (59265966 bytes received so far) [generator] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [generator=3.1.0] The first error (inflate returned -3 (0 bytes)) was tracked in token.c: > case r_inflating: > rx_strm.next_out = (Bytef *)dbuf; > rx_strm.avail_out = AVAIL_OUT_SIZE(CHUNK_SIZE); > r = inflate(&rx_strm, Z_NO_FLUSH); > n = AVAIL_OUT_SIZE(CHUNK_SIZE) - rx_strm.avail_out; > if (r != Z_OK) { > rprintf(FERROR, "inflate returned %d (%d bytes)\n", r, n); > exit_cleanup(RERR_STREAMIO); > } > if (rx_strm.avail_in == 0) > recv_state = r_inflated; > if (n != 0) { > *data = dbuf; > return n; > } > break; The problem is that -3 refers to Z_DATA_ERROR. This error is returned whenever the zlib state machine enters the "BAD" state (inflate.c), e.g. > case HCRC: > if (state->flags & 0x0200) { > NEEDBITS(16); > if (hold != (state->check & 0xffff)) { > strm->msg = (char *)"header crc mismatch"; > state->mode = BAD; > break; > } > INITBITS(); > } Note that zlib does have an error message in addition to the error code. It would be very nice if rsync could print the zlib error message alongside the error code and result buffer size. I currently can't get enough information from the provided error message to decide if it's an rsync/zlib problem (very unlikely IMHO) or a hardware issue.
I think this bug is affecting us too, over multi-gigabyte files. There's one specific file which is killing rsync, but it doesn't always kill it in the same place.
Anyone experiencing a similar issue may want to have a look at bug 10372 . ( Possibly related: bug 10332. )