exit status 13 in version 3.1

[Wayne Davison]

On Thu, Nov 12, 2009 at 10:00 PM, Matt McCutchen <matt at mattmccutchen.net>wrote:

> My point is that it's a clunky way to achieve the goal, and it would be
> simpler for the sender to just keep reading after a write error.
>

Yeah, that's a good idiom, and the latest code wasn't doing a good enough
job of that when the socket closed.  One new issue turned out to be that the
client started getting a read error (where the old code would get a write
error) due to the buffer-filling code getting an EOF on the socket (even
though the perform_io() call was ostensibly there to try to write some
data).  There was also a bug where an EOF error did not try to empty out any
message data currenly in the buffer.

I've committed some improvements for this, so the error reporting should be
better when talking to older versions.  For instance, the input code now
just notes an input EOF unless it is there to read some data and the data is
not present.  It also does a better job of draining any pending error
messages from the input buffer (and reading any final messages) when a write
error occurs.

As for the arbitrary io_timeout that gets set, yes, it is debatable if it is
a good idea.  While not strictly necessary, I kind of like having it just as
a final sanity check for the error-exit code.  I did make the arbitrary
timeout larger, though, since it should not ever really be needed.  I'll
also review the error-handling a bit more, and possibly reconsider this
further.

..wayne..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20091115/8b1541f7/attachment.html>