Yakov Hrebtov jake at
Mon Oct 30 06:45:00 GMT 2006

Wayne Davison wrote:
> 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

As I mentioned before, I'm using now two FC5 boxes for playing with iconv.
Default charset on both sides is en_US.UTF-8.
When I use --iconv=. to transfer between these servers, I expect no conversion
at all. But I've got:

client charset: UTF-8
server charset: ISO-8859-1

Swaping client and server doesn't change anything. Server says its charset is
ISO-8859-1 (If the same machine is client then charset is correct UTF-8).

`echo $LANG` returns en_US.UTF-8 on both sides.

I just found the culprit of this problem.
Rsync daemon is works via xinetd in my system. In this case wrong character set
is determined. This problem disappear, if using straight listening rsync daemon.
It seems, xinetd for eny reason, passes to rsync wrong environment when forking
the server.

More information about the rsync mailing list