another iconv question

[Robert DuToit]

On Mar 31, 2008, at 10:14 PM, Wayne Davison wrote:
> On Mon, Mar 31, 2008 at 09:54:16AM -0400, Robert DuToit wrote:
>> we tried adding option iconv=C and iconv=C,C  but no luck

oddly this is what was returned when he ran "locale" on his machine-it  
didn't specify a locale or charset:

xserve-backup-02:/Volumes/Backup RAID 8TB teleclub$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL="C"

but I found this for German-Swiss in my "locale -a" list:

de_CH.ISO8859-1
de_CH.ISO8859-15
de_CH.UTF-8

so we are not sure which charset to use with iconv=.

  ISO8859-1 or ISO8859-15 or UTF-8?


>>
>
> That would appear to be a request for rsync to not do any character
> conversion, in which case you shouldn't be using --iconv.
>
> When using the --iconv option, you should describe the character set
> that the files are in on the disk on both the sender and the receiver.
>
>> [rsync] re-copies [e]very file with an umlaute.
>
> Are you using (or implying) the -t (--times) option?  (Use the -i  
> option
> to see if the copy is due to time changes or something else.)  What do
> you mean by "re-copies"?

when he runs rsync again, it creates a new copy of the files (with  
umlautes) even though they aren't changed. He said the mod times are  
the same on sender and receiver.

> Are you talking about copying the file away
> and back again, which creates an extra copy of the file on the source
> machine under a slightly different name?  If so, perhaps that  
> character
> cannot be converted to UTF-8 and back without changing in the process.
>
> If you're talking about a single direction, make sure you've specified
> the right character set for each machine.  Also make sure that the  
> file
> wasn't copied before with the wrong character set, since the new file
> might be the right one.

Yeah- he ran it many times and it always copies over the umlaute  
files. I'll experiment with the de_CH charsets above though. Thanks, Rob

>
>
> ..wayne..