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.
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
