documentation bug for --daemon "use chroot" in conjunction with -o and -g

[pyxl]

Hi all,

Tripped over a documentation bug.  I'm guessing the behavior I've found 
isn't a bug in itself as it's kind of implied by chroot (unless the 
/etc/passwd db is read *before* you do the chroot call), so I'm calling 
it a documentation bug.

The Setup:

System A:  running rsync --daemon from xinetd, configured with a 
read-only share.
System B:  syncing a local directory structure from the share on System A.
Both running Red Hat Linux 7.2, and rsync 2.5.4

The Problem:

The documentation indicates that -o and -g on the client side preserve 
the user and group of the files/dirs transferred as compared by name 
(i.e. for sync A=>B, if the uid for "bob" is 205 on A, and 3328 on B, 
then the uid of the file will be converted transparently to 3328 on B 
during a sync).  HOWEVER, what isn't mentioned in the man page for 
either rsync or rsyncd.conf is that for the -o and -g options to work, 
the server side MUST have "use chroot = no" in the config file.  As the 
default behavior for rsync is "use chroot = yes", this can make things 
frustrating when the directions and the behavior don't quite sync (pun 
gleefully intended) up.  It ends up setting the uid and gid to the 
numeric ids from the server side, which is functionally equivalent to 
using --numeric-ids (with variations based on what user the client side 
is running as).

The Solution:

Mention on the rsync man page in the -o and -g descriptions that syncing 
from a --daemon based share requires that "use chroot = no" be specified 
in the rsyncd.conf, and mention on the rsyncd.conf man page that if "use 
chroot = no" isn't specified in the rsyncd.conf that -o and -g will not 
work on the client side.

Thanks for your attention,

Scott