with the new error handling code it is possible for rsync to get stuck
on the final transaction, leaving it hung.

looks like 2.4.1 will be pretty soon

the last pre-release had a bug that didn't setup the multiplexing
correctly. This means that pre-release will get "unexpected tag -7"
whenm talking to the fixed code.

its all too common to compile with a working libc and run on a broken
one.

  connections (this fixes the stderr/stdout problem). Upped
  protocol version for backward compat
- use multiplexing on error fd
- upped minimal protocol version
- got rid of some ugly code in the write buffering

ssh clag problems as long as you also fix the same problem in sshd

removed all the old read buffering code from io.c as this was only
there to try to reduce the chance of clagging up sshd.

(was a minor bug in send_file_list)

cross-filesystem

my system the LIBC tests meant it never compiled and we used the
broken system one.

hacked it so it does compile

when using --progress

of memory vs. ssh bugs. uggh.

inet_addr(). Some systems were detecting a missing inet_aton(), but
actually had it and inet_addr() called it, causing infinite recursion

another program) during an update

pointed out by byrnes@curl.com

root, leaving a corrupt filesystem. Are those guys on drugs?

try to avoid the problem as best we can.

receive_file_entry" message

this is very useful for incremental backups

out to be caused by it and it seems rather a lot of extra effort for
what must really be a minor optimisation in most cases

(thanks to T.J.Adye@rl.ac.uk)

Thanks to roebel@kgw.tu-berlin.de

clients when writing to a rsync server

it works like this:

- we have an extra pipe from the receiver to the generator
- the server always runs with multiplexing on
- errors from the generator go down the multiplexed connection
- errors from the receiver go over the pipe, and from there to
  the multiplexed conn

it required some incredibly ugly code. damn.