Wayne Davison wrote:> On Fri, Oct 27, 2006 at 04:19:06PM +0600, Yakov Hrebtov wrote: >> This test compiles and executes without "failed" message. Hence >> iconv_open("UTF-8","CP1251") succeeded. > > Check to see if the two programs are linking differently. Perhaps > configure decided that it needed -liconv when that that library > doesn't really work?$ nm ./test | grep iconv U iconv_open@@GLIBC_2.1 $ nm ./rsync | grep iconv U iconv@@GLIBC_2.1 U iconv_open@@GLIBC_2.1 08091cfc B iconv_opt 0804ada0 T setup_iconv As I undersnand, programs are linked equally?> Also, did you run the test program on the same machine that is logging > the error? (I assume the sending/server side, not the client side.)Sure. When I started to play with iconv, I've used ALT linux (russian distribution) box as CP1251/server/sending (problem) side. After some experimetation, I decided to use other server to exclude possible ALT linux box misconfiguration. Trying another server didn't help. iconv_open failed message still appears. Now I'm using two very similar-configured FC5 boxes. And I run test on both sides. One more note here. If CP1251 side is sending as client (UTF-8 is on server/receiver), then there are no errors. $ rsync -av --iconv=CP1251,UTF-8 /var/data/tmp/ \ rsync@192.168.210.14::userdata/tmp/ This command successfuly transfers files and converts filenames.> Did you double-check the raw filenames to see if the byte sequences > that were causing the problems were actually stored in ru_RU.CP1251?CP1251 test files are created, using samba server with unix charset = CP1251. Moreover, seems to me that error appears in setup_iconv, so no actual file transfer at this moment?> If that doesn't help you to clear up the problem, you might try > specifying a more complete description of the character-set that > you want in place of CP1251: > > rsync -avH --delete --iconv=UTF-8,ru_RU.CP1251 \ > rsync@virgo.generation.int::users/Service/Jake/ \ > /var/data/users/This doesn't help: iconv_open("UTF-8", "ru_RU.CP1251") failed> Finally, it is helpful to post to the mailing list instead of sending me > emails directly because (1) someone else may be able to help you, and > (2) if we solve the problem, we'll have a record of the solution in the > archive.Agreed, sorry.
Yakov Hrebtov wrote:> One more note here. > If CP1251 side is sending as client (UTF-8 is on server/receiver), then > there are no errors. > > $ rsync -av --iconv=CP1251,UTF-8 /var/data/tmp/ \ > rsync@192.168.210.14::userdata/tmp/ > > This command successfuly transfers files and converts filenames.It seems, server side cannot do any conversions... As I understand, sender side converts filenames to UTF-8 from source charset, and receiver side converts from UTF-8 (transport charset) to destination charset. If charset on server side (no matter receiving or sending) differs from UTF-8 (so conversion to/from UTF-8 must be done), then it always failed to iconv_open (for unknown reason). The same iconv_open succseeded, if the same conversion must be done in rsync-client.
Yakov Hrebtov wrote:> It seems, server side cannot do any conversions...May be it's chroot-related issue? I will check it tomorrow!
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 problem. ..wayne..