Wayne Davison wayned at
Sun Oct 29 14:34:53 GMT 2006

On Sun, Oct 29, 2006 at 11:57:17AM +0500, Yakov Hrebtov wrote:
> If CP1251 side is sending as client (UTF-8 is on server/receiver), then 
> there are no errors.

How very strange.  I just ran a test here, and I had no problem getting
the server side to use CP1251.

> Moreover, seems to me that error appears in setup_iconv, so no actual file 
> transfer at this moment?

You cited some filename conversion errors when you used --iconv=. which
is what spurred my question.  I consider the --iconv=. option to be the
preferred usage (when possible) because it is easy to put a "." in the
RSYNC_ICONV environment variable and have it "do the right thing" for
all transfers, but it only works as long as the default environment has
the right charset configured on each side.  If you use -vv, you will be
told what charset each side is using for an --iconv=. transfer.  e.g.:

server charset: CP1251
client charset: UTF-8

Perhaps there is a different library load path that the daemon is
running under than there is when running the fetch as a client?  If you
are using an inetd daemon setup, try switching to a straight rsync
daemon setup and see if that helps.  If you are already running such a
daemon, try checking your environment for differences between the user
that starts the daemon and the user that has a successful client run.
You might also try starting the daemon as a non-root user (using a
non-privileged port), and see if it behaves differently.  I'm just
guessing at ideas here, since I can't get it to fail, this is the kind
of detective work you'll need to do to figure out what is causing the


More information about the rsync mailing list