similar to: [PATCH] build fix without iconv support

https://bugzilla.samba.org/show_bug.cgi?id=5075 Summary: Syncing with --iconv may yield protocol error Product: rsync Version: 3.0.0 Platform: All OS/Version: All Status: NEW Severity: major Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: lennart.samba@lovstrand.com

This patch adds a switch --fat-filenames which replaces all characters that aren't legal on FAT filesystems with an underscore. This is the first time I touch the rsync code, so I may not be going about it the right way, but it seems to be working. Naturally there's some potential for collisions, but it's probably better than what happens currently (such files are simply not copied).

In debian bug #493559 (http://bugs.debian.org/493559) the problem is that when requesting a file from an older version rsync, the remote server gives an error: $ rsync rsync://rsync.blackholes.us/zones/countries/countries.rbl /tmp rsync: on remote machine: -: unknown option rsync error: requested action not supported (code 4) at clientserver.c(517) rsync: connection unexpectedly closed (4 bytes

https://bugzilla.samba.org/show_bug.cgi?id=5012 Summary: iconv: client charset used by server process Product: rsync Version: 3.0.0 Platform: PPC OS/Version: Mac OS X Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: kaarle@web.de

If rsync is called with -4 or -6, that option is currently ignored when ssh is used as the transport. The attached patch is a stab at passing the option on to the ssh process. It checks that the remote shell program is something that looks like ssh. Perhaps that could be done cleaner... Paul Slootman --- a/main.c 2008-03-01 21:01:41.000000000 +0100 +++ b/main.c 2008-03-04 18:55:10.933488013

Hi, first of all, sorry for taking so long. Unfortunately, some other tasks kept coming up. Anyway, attached is the version of the flags patch, that is based on the one I'm using with 2.6.9. It is against the rsync-3.0.0pre9 release. I've included the option name change from the repository, so the option is now called --fileflags. Improved from the previously distributed version is the

Hello, I am trying to get rsync-3.0.0pre10 --iconv option working between two linux hosts in local network. The client host is running Fedora Core 4 (kernel 2.6.17) and is using iso8859-1 character set. LANG=en_US The daemon host is running Centos 5 (kernel 2.6.18) and is using utf-8 character set. LANG=en_US.UTF-8 Rsync is transferring files properly without --iconv switch: fc4: (connected

Hi Folks, Well, it has only been more than 6 weeks and still no response to my "No localisation for rsync?" topic. :( So far, I have determined that there are at least 4 files that need translations for rsync. They are the following. main.c flist.c log.c progress.c For my initial test I only made the following modifications. main.c ------ I added the following line ... #include

Hi, When using the latest rsync 3.1.0 client, connecting to a pre 3.1.0 (i.e. 3.0.9 and earlier, protocol version 30) server running in daemon mode and requesting a recursive (incremental by default) file transfer, the variable use_safe_inc_flist is not set (affecting how I/O errors are handled during file list generation). so it is set for: 3.0.9 client -> 3.0.9 daemon 3.0.9 client ->

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 >