----- Original Message -----
From: "Damon Register"
Brian K. White wrote:
Sounds like you're on track. I thought I was but it is far from over.
However, I would (I do in fact) just install the prebuilt rsync from sunfreeware. I just did. I tried building it from source but that didn't get very far so I just got the prebuilt packages from SFW. I tested with that and still get the same old
You said you have solaris 10, I don't remember what platform, so, assuming it's sparc, It is an Ultra20 with an AMD64.
for you to install rsync, you could cut & paste this recipe verbtim, paste the whole block from sfi () { to } right into a telnet/ssh session. Then run the sfi <pkg> commands manually one at a time, in the order shown. That's a cool script. Thanks.
If you don't have wget or curl just get the files any way you want of course and run the gunzip & pkgadd commands manually like the first example. I had to get those a while ago for some reason I don't remember any more.
So far everything I tried gives me the same error.
rsync: The server is configured to refuse --iconv rsync error: requested action not supported (code 4) at clientserver.c(840) [receiver=3.0.3] rsync: connection unexpectedly closed (5 bytes received so far) [sender] _exit_cleanup(code=12, file=io.c, line=635): entered rsync error: error in rsync protocol data stream (code 12) at io.c(635) [sender=3.0.3] _exit_cleanup(code=12, file=io.c, line=635): about to call exit(12)
No matter what options I try, I still get the "refuse --iconv" message. I got the impression from the man page that if I didn't specify a charset that the iconv would be refused unless I added no-iconv to the refuse options.
Since I wasn't getting anywhere with the Solaris setup, I installed SuSE 11 on an old spare PC. After getting the rsync daemon setup there, I tried it and got the same message. It seems that the rsync daemon on the SuSE system has the same problem. So, since the SuSE setup has the same problem I will focus on that first since I might have a better chance of getting help. Perhaps if I get the SuSE one working, I will have found the solution for the Solaris one as well.
Can anyone help with rsync on SuSE?
"man rsync", under --iconv=CONVERT_SPEC says nothing will happen unless there is a charset option in the daemon config file I put "charset = cp437" into /etc/rsyncd.conf on a remote machine and restarted rsyncd. and it says to use --iconv=local_charset[,remote_charset] and that valid values for charsets come from "iconv -l" first I tried a few tests with iconv itself, not involving rsyc, just to get so I know how to use iconv itself. After a lot of tests I'm not so sure this option is going to be very useful. It fails way too easily, saying that various characters are invalid either for the input or output character set. Even when both character sets do have the same character, iconv fails to translate them many times. However, eventually I arrive at a comand that converts something to something else, correctly. windows cp1252 has an e-umlaut at hex eb http://en.wikipedia.org/wiki/Windows-1252 cp437 has e-umlaut at hex 89 http://en.wikipedia.org/wiki/Code_page_437 Lets try to get iconv to translate the e-umlaut from windows to vga Rather than look at the character as displayed by my terminal, this email client, your email client, etc... lets just look at the output of "od" to remove the bezillion ambiguities. nc7:~ $ echo -e "\xeb\c" |od -h 0000000 00eb 0000001 (echo \xeb , no translation, and od -h shows 00eb as expected, now add iconv without changing anything else) nc7:~ $ echo -e "\xeb\c" |iconv -f cp1252 -t cp437 |od -h 0000000 0089 0000001 nc7:~ $ So now we have sample data that we know iconv can translate, and we know the valid iconv charset specifiers. _now_ try applying them to rsync. On the remote machine I create a file with a hex eb in it's name. nc7:~ $ mkdir i nc7:~ $ cd i nc7:~/i $ touch `echo -e "h\xebllo"` nc7:~/i $ ls --show-control-chars hëllo nc7:~/i $ Based on the iconv section of the man page, because my local & remote machines have the same default LANG and LC_* settings, it appears --iconv=. will not do anything, and so I need to specify at least a local character set. On the local machine, try to download the directory containing the file and convert from windows-1252 to cp437 (I don't want to have to specify that funky character on the command line, and I don't want to figure out should I use hex 89 on the local end in order to request a file with hex eb on the remote end? etc.. just get the whole directory. get fancier later if necessary.) nj2:~ $ rsync -avz --iconv=cp437,cp1252 nc7::bkw/i . receiving incremental file list rsync: The server is configured to refuse --iconv rsync error: requested action not supported (code 4) at clientserver.c(842) [sender=3.0.2] rsync: read error: Connection reset by peer (104) rsync error: error in rsync protocol data stream (code 12) at io.c(759) [receiver=3.0.0] nj2:~ $ Well the remote server has no charset option in it's rsyncd.conf, so now I add "charset = iso8859-1" to the remote servers /etc/rsyncd.conf, because although I'm translating from cp1252 to cp437, the remote server really isn't cp1252 in general and I don't want the remote rsync converting anyone elses files. Then restart rsyncd on the remote server. And try the same download again. Download with no conversion: nj2:~ $ rsync -avz --del nc7::bkw/i . receiving incremental file list i/ i/h?llo sent 77 bytes received 159 bytes 157.33 bytes/sec total size is 0 speedup is 0.00 nj2:~ $ Now with conversion: nj2:~ $ rsync -avz --del --iconv=cp437,cp1252 nc7::bkw/i . receiving incremental file list deleting i/h?llo i/hëllo sent 74 bytes received 157 bytes 462.00 bytes/sec total size is 0 speedup is 0.00 nj2:~ $ ls --show-control-chars i hëllo nj2:~ $ I think this is still full of problems. Almost all of my manual iconv test conversions failed. Too many times it said that a character was invald in either the input or output character sets. For instance, it wouldn't turn o-umlaut into a plain o if no o-umlaut existed in the output charset, nor would it pass the byte through without changing it, instead it output nothing except an error message. Adding -cs would hide the error messages and simply strip any bad characters, but that's not very useful for filenames. I don't know what your final answer should be other than forcing everything everywhere (samba and rsync) to use utf8 or utf16 so they all speak the same character set. -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org