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.

zlib header fiels in Makefile.in.  I've been burned several times because
objects did not get rebuilt when header files changed.

couldn't find some of them (especially <fnmatch.h>, because it wasn't
looking in the current directory).  The header files are included better
from ../rsync.h.

FNM_PATHNAME flag (to stop at slashes in path names) was not working.

Ironically, the bug in glibc's fnmatch was reported on the rsync mailing
list in late October, and rsync's configure.in was changed to detect the
bad glibc and use the internal fnmatch, but the internal fnmatch was based
on the same buggy glibc!

than skipping it and thus not updating it.  For example, the ownership or
mode on a file may prevent opening it, but the directory may still be
writable so the file could be completely replaced.

the file if the file has the setuid or setgid bits set as the chown
has a side effect of removing the setuid and setgid bits.
we re-do the stat in this case

was not preserving group permisions.  Bug was introduced March 1 in
version 1.100 of rsync.c with an error in re-ordering of the boolean
expressions.  In order to completely preserve the earlier semantics,
change_gid should depend on "(am_root || !am_daemon)", but I don't see why
group ownership should behave differently in a non-root daemon.

using all the mode bits of the existing file rather than just the permissions,
including the file type.