copy. This makes us match GNU cp more closely.

andrewdagger@xerox.gbr.com)

added note about multiple excludes per exclude option

so the check for dry_run and CHECK_RO are not done when flags is O_RDONLY.
Only do the adding of O_BINARY, which was the intention.

thanks to Dave for pointing this out.

preserve_perms is off.

it is equivalent to --partial --progress

working correctly.

and O_BINARY

Suggested by Roger Price <rprice@cs.uml.edu>

from Bob Edwards

One is a note that a leading "/" in a symlink target will not behave
exactly as if a chroot had occurred, but I decided it wasn't worth the
making it the same.

The other is note about an extra harmless trailing "." that is added under
some rare circumstances.

    1. The file paths being sent and received were not "sanitized" to
	ensure that there weren't any ".." components that would escape the
	top level directory.  This can't happen with the standard rsync
	client, but it could be exploited on both read and write if someone
	modified an rsync client.  This fix sanitizes all incoming and
	outgoing paths when "use chroot = no".

    2. If a module is also "read only = no", clients could have created
	symbolic links with ".." components that would allow writing
	outside of the module.  This could happen with the standard rsync
	client.  This fix sanitizes all incoming symbolic link targets
	when "use chroot = no".

Previously, only top-level paths (anything passed in command line arguments)
were sanitized.  Sorry, I didn't think about the individual file paths
before now.

Matti Aarnio)

comparing checksums for the --checksum (-c) option.

rsync servers via a web proxy (useful for getting through firewalls)

catches most sorts of io errors and ensures we report a error in our
exit status.

all files have been excluded).

1) rsync won't copy directories at all if recursion isn't selected
2) --delete won't do anything if recursion isn't selected

rsyncd.conf are not passed to the client and thus only affect the file
lists on the server.

permissions on directories after a transfer.

patch from racke@linuxia.de

hadn't changed but its permissions had, the file wasn't copied but
its permissions were attempted to be set anyway.  Made a change to
skip setting the permissions in that case.

--compare-dest.  It was due to an incomplete analysis of the problem,
sorry.  I left a comment in its place indicating that normally the
parent directories should already have been created.

It turned out to actually be a bug in nsbd in which it was not always
including all the parent directories in the include list like it was
supposed to.  The files themselves were still being sent but that was only
because my exclude_the_rest optimization was kicking in; if it weren't,
excluding the parent directories would have had the side effect of
excluding the files too.  So it really had nothing to do with the
--compare-dest option after all, just with the requirement that if you use
--exclude '*' you need to explicitly include all parent directories of
files you include.

because at that point in the program the umask is set to 0.  Now creating
the file with mode (666 & ~orig_umask).

target destination were not getting created.  There was a case in
receiver.c to do that but it was only getting invoked when the -R option is
specified, although I don't know why it was limited to that.

It's too bad I didn't get a chance to more fully test the use of
--compare-dest by my nsbd program before releasing rsync 2.3.0.  I'll
probably need to put a workaround in nsbd too until the next release
of rsync.

both directions.

I'll be encouraging extra testing before the release.

Patch submitted by Damian A Ivereigh <damian@cisco.com>

of cygwin doesn't work.  Thanks to Martin Krumpolec <krumpo@pobox.sk> for
the patch.  At the same time, include cache checks in configure.in for a few
items that were missing the checks.