Mailinglist Archive: opensuse (1606 mails)

< Previous Next >
Re: [opensuse] strange samba rsync problem gets worse

----- Original Message -----
From: "Damon Register" <damonregister@xxxxxxxxxxxxx>
To: <opensuse@xxxxxxxxxxxx>
Sent: Friday, September 05, 2008 7:50 PM
Subject: Re: [opensuse] strange samba rsync problem gets worse

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
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)
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)
_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
I put "charset = cp437" into /etc/rsyncd.conf on a remote machine and restarted

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

cp437 has e-umlaut at hex 89

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

(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
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
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)
rsync: read error: Connection reset by peer (104)
rsync error: error in rsync protocol data stream (code 12) at io.c(759)
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

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

sent 74 bytes received 157 bytes 462.00 bytes/sec
total size is 0 speedup is 0.00
nj2:~ $ ls --show-control-chars i
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@xxxxxxxxx
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups