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.

the receiver even when not combined with -r.  Without this, the directories
were getting created mode 777 because the default umask on receivers is
often 00.

executable is busy on HPUX), rename it instead to .rsyncNNN.  Most of
the code was submitted by Ketil Kristiansen <ketil-k@osc.no>

David Campbell <david@pastornet.net.au> reported that that helps data
be received onto a windows box running cygwin b19.

I believe this is the latest, which comes with automake 1.4 (somebody
else is in charge of installing the GNU stuff on my system so I'm not
100% sure it's the absolute latest, but it was updated just a couple
weeks ago).

other access resulted in group and other access being left off when the
'-p' option was not used.  This fixes it by reintroducing the ACCESSPERMS
mask and setting permissions to (file->mode & ACCESSPERMS) if preserve_perms
is off.  I decided to change the mask INITPERMMASK to INITACCESSPERMS at
the same time.  When preserve_perms is off, rsync is restored to the
previous behavior of having the permissions of the original file with the
umask and setuid/setgid bits shut off.

Also, I decided that a check for "(updated && (file->mode & ~ACCESSPERMS))"
is no longer needed since as far as I can tell that would have only affected
permissions when not running as root and when a chgrp was done to a group
the user was not a member of, using system V chgrp semantics.  This is no
longer allowed.

whenever delete_mode is on.  People reported problems when it kicked in
while using --delete and while using --delete-excluded.

as calculated by the configure macro AC_TYPE_GETGROUPS.  Without that, it
doesn't work properly on systems like sunos 4 where gid_t is defined to
be an unsigned short but getgroups is defined to return an array of integers.

an obscure race-condition security hole where a file may for a short time
have the wrong group.  Could have used 707 instead but that's just too weird
of a permission.  The define name used to be ACCESSPERMS but that is defined
as 777 on Linux, so changed the name to INITPERMMASK.

such as sunos4 gid_t is an unsigned short.  This prevented the just-added
non-mapped group test from working on sunos4.

does not belong to, in these two ways:
    1. If a group mapping doesn't exist for a group name, do not preserve
	it for a non-root receiver.  This is especially evident with the
	sender is a daemon using chroot because then no mappings are
	available.
    2. Before setting the group on a file make sure that it is in the list
	of groups returned by getgroups().  The same thing is done by chgrp
	on systems that support bsd-style chown/chgrp, and this enforces
	that it happens the same way on all systems.  Overhead is very
	little, especially since most systems don't allow more then 16
	groups per user.

of a socket (that is, a --daemon) server, but never looked at.  The way to
test whether or not on a client is (!am_server).

are excluded.  Implies --delete.

situations:
    1. the client is the receiver of files.  Can't do it otherwise yet
	because without -v the bytes written from the sender's generator
	process will not be counted.
    2. both the remote and local protocol versions are >=20.  I did not
	change the protocol version yet because it is such a minor change
	that it isn't worth it, although I did test it with the protocol
	version set to 20.
If neither of the situations hold, it prints a message saying to use -v.

slashes.  The old behavior of crossing slashes can be achieved by using a
double-asterisk ('**') anywhere in a pattern.  Note that this can change
some existing exclude patterns in a subtle way.  Also note that if the
remote side is an older release the processing on the two sides might not
be exactly the same when there's no double-asterisk, which can affect which
files are excluded from deletion, but they're close enough that people will
probably not notice.  I considered changing the protocol version and
checking the remote_version number to ensure the same processing on both
sides, but the exclude patterns are pre-processed before the remote version
number is known and it's just not worth going through extraordinary efforts.
Suggested by Cameron Simpson <cs@zip.com.au>

ftp based mirror system so that timestamps may not be right.

any more except in very obscure cases.

only for symlinks that point outside the source tree.  Suggested by Charles
Hines <chuck_hines@VNET.IBM.COM> in PR#1376.  Also apply the option to any
symbolic links in the source portion of a path when --relative is used,
as suggested by Francis Montagnac <Francis.Montagnac@sophia.inria.fr> on
the rsync mailing list in a message titled "New option: --copy-parent-links".

of memcpy because bcopy is guaranteed to work with overlapping memory and
memcpy is not.  Bug fix for PR#1584 in which log entries in the rsync
daemon log on Sunos 4.1.4 were garbled.

was incorrect.  It's hard to tell how many bytes are actually read because
transferring the value changes it and depending on its value it may
transfer 4 or 12 bytes so instead change the sender side to not include the
length of the counters it sends at all (it had been including one but three
are sent).

multiple SRCs.  Also moved the --suffix option to show up right after
--backup and included the default backup suffix and block size along with
their corresponding options rather than at the end.  Copied the new help
message to rsync.yo and README and used the Usage also in the SYNOPSIS
section at the top of rsync.yo rather than the different one that used
"path" instead of SRC and DEST.  That last change was inspired by a
suggestion from Michael Bleyer in PR #1523.

in receiver.c because it confuses people when they do something like
    rsync /etc/passwd /tmp/nonexistentdir/passwd
and it printed out something like
    open /tmp/noniexistentdir/.passwd.a004d5 : No such file or directory
Reported by kurt_granroth@pobox.com in PR #1253.

of non-wildcard includes followed by an exclude of *) so that it will silently
ignore included files that don't exist rather than saying "No such file or
directory".  This is more like the behavior of the non-optimized include mode.

probably cause any harm if they were treated as normal exclude or include
patterns because they just wouldn't match anything, but it's better to
explicitly ignore them.  Suggested by David Holland <uholld1@lexis-nexis.com>