On March 3, 2025 10:28 PM, Kevin Korb wrote:
>Works for me...
>$ ./configure --disable-iconv --disable-locale --disable-openssl
>--disable-xxhash --
>disable-zstd --disable-lz4 && make $ ldd rsync
> linux-vdso.so.1 (0x7ffd39873000)
> libc.so.6 =>
Works for me...
$ ./configure --disable-iconv --disable-locale --disable-openssl
--disable-xxhash --disable-zstd --disable-lz4 && make
$ ldd rsync
linux-vdso.so.1 (0x7ffd39873000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f77c8f8b000)
/lib64/l
y has 32-bit builds. The --disable-iconv option in configure
>> is not actually disabling iconv. Is there a different option to
>> disable this, at least temporarily?
>
>Try --disable-locale.
Sadly, that made no difference. Libiconv.so still required.
--
Please use reply-all for
On Mon, 2025-Mar-03, Randall S. Becker via rsync wrote:
I am trying to build a 64-bit version of rsync. My issue is that I do not
have a 64-bit libiconv.so
or libiconv.a available. The platform I am on only has 32-bit builds. The
--disable-iconv option
in configure is not actually disabling
Hi Rsync Team,
I am trying to build a 64-bit version of rsync. My issue is that I do not
have a 64-bit libiconv.so
or libiconv.a available. The platform I am on only has 32-bit builds. The
--disable-iconv option
in configure is not actually disabling iconv. Is there a different option to
disable
https://bugzilla.samba.org/show_bug.cgi?id=14401
Wayne Davison changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|REOPENED
https://bugzilla.samba.org/show_bug.cgi?id=14401
--- Comment #10 from Tormen ---
Thank you very much ! for your comments.
I agree that the problem I pointed out would be then a limitation of iconv.
The comment about not converting was really helpful. I was not sure about
leaving the --conv
n any case, this sounds like an iconv issue, not an rsync issue.
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rs
https://bugzilla.samba.org/show_bug.cgi?id=14401
--- Comment #8 from SATOH Fumiyasu ---
The U+1F6C4 (BAGGAGE CLAIM emoji, <9F><9B><84> in UTF-8) is a Unicode
character and is located in surrogate pairs, but the UTF-8-MAC encoding by
macOS's iconv(3) does not support s
https://bugzilla.samba.org/show_bug.cgi?id=14401
--- Comment #7 from SATOH Fumiyasu ---
The `
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists
|--iconv=utf-8-mac,utf-8 |--iconv=utf-8-mac,utf-8 --
||"ls" in "Terminal" App
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid omitting the mailing lis
https://bugzilla.samba.org/show_bug.cgi?id=14401
--- Comment #6 from Tormen ---
Created attachment 16020
--> https://bugzilla.samba.org/attachment.cgi?id=16020&action=edit
File breaking the rsync --iconv=utf-8-mac,utf-8 -- in Finder
--
You are receiving this mail because:
You are
https://bugzilla.samba.org/show_bug.cgi?id=14401
--- Comment #5 from Tormen ---
> If the iconv library complains about the encoding, then either the encoding
> name is wrong or you have an invalid file that isn't named with the specified
> encoding.
How can I "zoom in&quo
https://bugzilla.samba.org/show_bug.cgi?id=14401
--- Comment #4 from Tormen ---
Created attachment 16019
--> https://bugzilla.samba.org/attachment.cgi?id=16019&action=edit
File breaking the rsync --iconv=utf-8-mac,utf-8
--
You are receiving this mail because:
You are the QA Contact
https://bugzilla.samba.org/show_bug.cgi?id=14401
Tormen changed:
What|Removed |Added
Resolution|WORKSFORME |---
Status|RESOLVED
https://bugzilla.samba.org/show_bug.cgi?id=14401
--- Comment #3 from Tormen ---
Created attachment 16018
--> https://bugzilla.samba.org/attachment.cgi?id=16018&action=edit
File breaking the rsync --iconv=utf-8-mac,utf-8
--
You are receiving this mail because:
You are the QA Contact
rictHostKeyChecking=no -o
UserKnownHostsFile=/dev/null' -D --numeric-ids --links --hard-links
--one-file-system --itemize-changes --times --recursive --perms --owner --group
--stats --human-readable --partial --delete --iconv=utf-8-mac,utf-8 --compress
--log-file '/Users/admin/.rsync-tmbackup/20
|--- |WORKSFORME
--- Comment #1 from Wayne Davison ---
Macs use a weird utf-8-mac encoding that you need to make sure you're
specifying. If the iconv library complains about the encoding, then either the
encoding name is wrong or you have an invalid file that isn't name
https://bugzilla.samba.org/show_bug.cgi?id=14401
Bug ID: 14401
Summary: unicode character conversion problem from MacOS to
Linux despite iconv
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
https://bugzilla.samba.org/show_bug.cgi?id=13492
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.samba.org/show_bug.cgi?id=13492
Bug ID: 13492
Summary: report modified dir when using iconv
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
Severity: normal
Hi
I need -iconv option, but configure didnt find iconv
$ cygcheck -c libiconv
Cygwin Package Information
Package VersionStatus
libiconv 1.14-3 OK
$ ./configure --enable-iconv=yes --disable-acl-support
...
checking for library containing iconv_open
Hi
I need -iconv option, but configure didnt find iconv
$ cygcheck -c libiconv
Cygwin Package Information
Package VersionStatus
libiconv 1.14-3 OK
$ ./configure --enable-iconv=yes --disable-acl-support
...
checking for library containing iconv_open
I am having a problem using rsync 3.1.2 to backup a remote linux machine to
local OSX machine. It works fine, but one large directory full of files has a
lot of files with foreign characters in the filenames and this blows up rsync.
I tried to use:
—iconv=utf-8-mac,utf-8
But still it
I am trying to use iconv to copy files from a UTF-8 machine to a iso8859
machine. The target is an embedded box with no UTF-8 support.
I've tried both --iconv=utf-8,iso88591 and --iconv=. and the result is
the same:
[sender] cannot convert filename: Chris Botti _ Michael Bubl\#351
(In
than looking for just
iconv.)
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change
https://bugzilla.samba.org/show_bug.cgi?id=8018
Summary: configure doesn't find iconv library
Product: rsync
Version: 3.0.8
Platform: All
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priorit
On Thu, May 20, 2010 at 12:04 AM, juligo wrote:
> Rsync: connection unexpectedly closed <0 bytes received so far> [sender]
>
If you didn't have a "charset = utf-8" option in the daemon rsyncd.conf,
rsync would have reported back that the daemon was refusing the --iconf
option. The error above p
conversion between both machines I use the ‘—iconv=850,UTF-8’ –
switch.
chcp told me that 850 is my codepage on my windowsmachine and locale on
Linux said ther UTF-8 is the current code page.
Now I use the command
Rsync.exe –agzv –-iconv=850,utf8 /cygdrive/source Rsync://destination
my output says
https://bugzilla.samba.org/show_bug.cgi?id=5615
--- Comment #8 from per_angst...@autark.se 2009-09-11 02:38 CST ---
My issue seems to be fixed in rsync version 3.0.6 protocol version 30. Tested
in Ubuntu 9.10 Alpha 5.
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi
https://bugzilla.samba.org/show_bug.cgi?id=5615
--- Comment #7 from per_angst...@autark.se 2009-04-01 11:29 CST ---
Thanks for the work-around. Hoping a fixed version is available soon.
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
--- You are receivi
ork around the issue by putting the support/lsh script on your path
somewhere, adding -e lsh to your rsync command, and making one of the args use
a localhost hostname. i.e., change the command in your test script to this:
rsync -ae lsh --iconv utf8,$SECONDARY_ENCODING \
./ localho
https://bugzilla.samba.org/show_bug.cgi?id=5615
--- Comment #5 from per_angst...@autark.se 2009-03-29 02:58 CST ---
Created an attachment (id=4033)
--> (https://bugzilla.samba.org/attachment.cgi?id=4033&action=view)
A bash shell script to test rsync's --iconv option on s
https://bugzilla.samba.org/show_bug.cgi?id=5615
--- Comment #4 from per_angst...@autark.se 2009-03-29 02:48 CST ---
Somehow I get the impression that the fix is either not in rsync 3.0.5, or it
does not work as intended.
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cg
--- Comment #3 from per_angst...@autark.se 2009-03-27 08:02 CST ---
I'm having problem with symlinks and rsync (3.05/Ubuntu 9.10) with the --iconv
option. I hope the following terminal log should make it pretty clear what my
problem is:
p...@barbaren:~$ rsync --version
rsync version
On Mon, 2009-03-16 at 14:42 +0800, Daniel.Li wrote:
> On Mon, 2009-03-16 at 14:08 +0800, Daniel.Li wrote:
> > Dear List,
> >
> > I have a quick question about rsync configuration.
> >
> > If I just simply use ./configure, does "--iconv" su
On Mon, 2009-03-16 at 14:08 +0800, Daniel.Li wrote:
> Dear List,
>
> I have a quick question about rsync configuration.
>
> If I just simply use ./configure, does "--iconv" supported by server?
>
> --disable-iconv disable rsync's --iconv option
O
Dear List,
I have a quick question about rsync configuration.
If I just simply use ./configure, does "--iconv" supported by server?
--disable-iconv disable rsync's --iconv option
Thanks.
--
Daniel
--
Please use reply-all for most replies to avoid omitting the m
https://bugzilla.samba.org/show_bug.cgi?id=6107
Summary: --disable-iconv does nothing
Product: rsync
Version: 3.0.5
Platform: Other
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P3
https://bugzilla.samba.org/show_bug.cgi?id=5615
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://bugzilla.samba.org/show_bug.cgi?id=5615
--- Comment #1 from [EMAIL PROTECTED] 2008-07-15 14:30 CST ---
Created an attachment (id=3410)
--> (https://bugzilla.samba.org/attachment.cgi?id=3410&action=view)
Screenshot showing symlinks not being iconv'erted
--
Configure bugmail
https://bugzilla.samba.org/show_bug.cgi?id=5615
Summary: iconv conversion not applied to symlinks
Product: rsync
Version: 3.0.3
Platform: Other
OS/Version: SunOS
Status: NEW
Severity: normal
Priority: P3
On Tue, Apr 01, 2008 at 11:12:03PM -0400, Matt McCutchen wrote:
> Thanks, but I noticed that you mangled the specifics on what HFS+ does.
I used the values rsync reported in the original email describing the
copying problem. I'll see if I can test the actual functioning.
..wayne..
--
To unsubsc
On Tue, 2008-04-01 at 19:59 -0700, Wayne Davison wrote:
> > Wayne, please consider adding this material to the "copies every file"
> > entry on http://rsync.samba.org/FAQ.html .
>
> I renamed the entry and added more info on extraneous copying. Thanks!
Thanks, but I noticed that you mangled the
On Tue, Apr 01, 2008 at 03:01:39PM -0400, Matt McCutchen wrote:
> the Mac OS X HFS+ filesystem has an annoying behavior of silently
> decomposing UTF-8 characters in filenames.
Ah yes, good point. I bet you're right about that.
> Wayne, please consider adding this material to the "copies every f
On Mon, 2008-03-31 at 09:54 -0400, Robert DuToit wrote:
> I am trying to help my friend set up his rsync with iconv. Presently
> it works fine but re-copies every file with an umlaute in the
> filename. I saw a recent post about this and the fix but...
>
> he ran "locale
On Tue, 2008-04-01 at 01:59 -0700, Kurt Martinsen 543 wrote:
> I have the same problem:
> received request to transfer non-regular file: 88183 [sender]
> rsync error: protocol incompatibility (code 2) at rsync.c(298)
> [sender=3.0.0]
>
> Is it just the one file that gets discarded or is it the who
Is it just the one file that gets discarded or is it the whole process that
stops at this point?
Any plans on releasing a new binary version including this fix anytime soon?
Regards,
Kurt
--
View this message in context:
http://www.nabble.com/Issue-with-rsync-3.0.0-and-iconv-tp16239983p164169
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 ch
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
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, yo
Hi All,
I am trying to help my friend set up his rsync with iconv. Presently
it works fine but re-copies every file with an umlaute in the
filename. I saw a recent post about this and the fix but...
he ran "locale" ( both source and dest are on same machine) and is
running o
Great, that was fast!
Thanks a lot for your work Wayne. I'll test it asap.
On Tue, Mar 25, 2008 at 6:58 PM, Wayne Davison <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 23, 2008 at 07:54:09PM +0100, Sergi Baila wrote:
> > 2008/03/23 19:27:37 [3760] received request to transfer non-regular
> file: 8630
On Sun, Mar 23, 2008 at 07:54:09PM +0100, Sergi Baila wrote:
> 2008/03/23 19:27:37 [3760] received request to transfer non-regular file:
> 86300 [sender]
OK: thanks to Sergi's off-list debug info, I've fixed the problem. It
was caused by a name that failed to convert on the sending side, and
tha
Thanks for your answer Wayne,
I've run the command with -vvv and got a 13 megs output. ;-)
The file bzipped is just under 1M, I can send to you directly by email if
you want.
There seems to be certain unsync between the moment this line appears:
received request to transfer non-regular file: 86
On Sun, Mar 23, 2008 at 07:54:09PM +0100, Sergi Baila wrote:
> 2008/03/23 19:27:37 [3760] received request to transfer non-regular file:
> 86300 [sender]
This means either that file-list number 86300 is not matching up between
the sender and the receiver, or that the data stream is somehow out of
Hello there,
I have a windows box (spanish locale, charset cp1252) which is backup to a
linux server via rsync. Until now I've had problems with file names
containing non us-ascii characters. Since the new stable version of rsync
with support for iconv I've upgraded rsync on my linux (
On Thu, Mar 20, 2008 at 07:19:14AM -0400, Robert DuToit wrote:
> A quick question. I tried --iconv=. but it didn't seem to work for my
> friend with umlautes in his file names.
Perhaps the default character set isn't set right for those filenames.
You can always specify the cha
Hi All,
A quick question. I tried --iconv=. but it didn't seem to work for my
friend with umlautes in his file names. In the archives I found
mention of a patch iconv.diff. Is that necessary or is it now
included in the source - it wasn't in my latest atches directory? Ro
On Tue, Mar 11, 2008 at 03:00:25PM +0100, Giuliano Gavazzi wrote:
> rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32)
This just tells you that the receiver side went away, but we don't know
why it went away. If it is crashing, try to get a core dump and report
the back
/local/bin/rsync -an --rsync-path=/usr/local/bin/rsync --
iconv=UTF8-MAC,437 /db /tmp/ rsync: writefd_unbuffered failed to
write 4 bytes [sender]: Broken pipe (32)
rsync: connection unexpectedly closed (9 bytes received so far) [sender]
rsync error: error allocating core memory buffers (code 22)
On Mon, Mar 10, 2008 at 10:37:51AM +, Stuart Halliday wrote:
> But I'm not using option --iconv!
It looks like the cwRsync binary was created with a default --iconv
option enabled (this is possible via a configure option). From the
other messages I saw, it appears that the de
quot;'Stuart Halliday'" <[EMAIL PROTECTED]>,
Date: Mon, 10 Mar 2008 12:05:41 +0100
Subject: RE: The server is configured to refuse --iconv
> See a related thread in cwrsync forum
>
> http://www.itefix.no/phpws/index.php?module=phpwsbb&PHPWSBB_MAN_OP=view
>
2008 11:38
> To: rsync@lists.samba.org
> Subject: The server is configured to refuse --iconv
>
> I've just tried upgrading to cwrsync 2.1.0 (Rsync version
> 3.0.0 protocol version 30) between 2 Windows XP Pro sp2
> machine across the Internet.
>
> I used:
> SE
When I run the above batch script on the remote machine I get this odd output.
sending incremental file list
rsync: The server is configured to refuse --iconv
rsync error: requested action not supported (code 4) at
clientser
On Thu, Feb 28, 2008 at 12:55:11PM +0200, [EMAIL PROTECTED] wrote:
> It would be good to add link to convmv script into rsync --iconv
> documentation. convmv can be found from http://www.j3e.de/linux/convmv/
Thanks. I have mentioned that utility on the rsync resources page.
..wayne..
> It was failing when communicating with a daemon due to a missing
> setup_iconv() call. The attached patch fixes this. Thanks for
> your report!
Thanks for the patch. I can confirm that --iconv option works now
from iso8859-1 to utf-8 transfer.
It would be good to add link to conv
On Tue, Feb 26, 2008 at 02:14:34PM +0200, [EMAIL PROTECTED] wrote:
> Has anyone got iso8859-1 to utf-8 conversion working with rsync-3.0.0pre10?
It was failing when communicating with a daemon due to a missing
setup_iconv() call. The attached patch fixes this. Thanks for
your report!
..wayne..
lly matter.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of [EMAIL PROTECTED]
> Sent: Wednesday, February 27, 2008 5:19 AM
> To: rsync@lists.samba.org
> Subject: RE: rsync-3.0.0pre10 and iconv
>
> > I think that UTF8
> I think that UTF8 is simply used as the transport encoding.
> The sending side will ensure that the filenames "on the wire"
> are UTF8, and the receiving side will convert that UTF8 into
> whatever is required.
I checked with tcpdump what is being transmitted between the hosts and found
that fi
On Wed 27 Feb 2008, [EMAIL PROTECTED] wrote:
>
> So if I'm interpreting that right, UTF8 is hardcoded to always be one of
> the conversion charsets. If rsync is sending, the conversion is always
> to UTF8. If rsync is receiving, the conversion is always from UTF8.
I think that UTF8 is simply used
sending, the conversion is always
to UTF8. If rsync is receiving, the conversion is always from UTF8.
To verify above, I tested to transfer the same two files to the other
direction (conversion from utf-8 to iso8859-1) and it worked properly.
Is --iconv option intentionally limited to only work f
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
Wayne already made this change to the development rsync in commit
15dbffc2.
Matt
On Wed, 2008-02-20 at 15:20 +0200, Antti Tapaninen wrote:
> diff --git a/clientserver.c b/clientserver.c
> index 2d7c28f..694a72d 100644
> --- a/clientserver.c
> +++ b/clientserver.c
> @@ -806,6 +806,7 @@ static int
diff --git a/clientserver.c b/clientserver.c
index 2d7c28f..694a72d 100644
--- a/clientserver.c
+++ b/clientserver.c
@@ -806,6 +806,7 @@ static int rsync_module(int f_in, int f_out, int i, char
*addr, char *host)
exit_cleanup(RERR_UNSUPPORTED);
}
+#ifdef ICONV_OPTION
> disk. It is started with the parameters
> --iconv=. what I suggest is the solution for syncing the attached file.
>
> log output in /var/log/messages
> received request to transfer non-regular file: 1706 [sender]
> rsync error: protocol incompatibility (code 2) at rsync.c(297)
so8859-15") failed
> > > > rsync error: requested action not supported (code 4) at rsync.c(120)
> > > > [receiver=3.0.0pre8]
> >
> > I already thought about that, but everything seems to work fine. I
> > created a file with some umlauts in UTF-8 and convert
On Sat, Feb 09, 2008 at 05:41:09PM -0500, Matt McCutchen wrote:
> This would be nontrivial to fix: in order to setup iconv before
> chrooting, the daemon would have to parse its arguments (to see the
> --iconv option) before chrooting
One other possibility is to implement something
On Sat, 2008-02-09 at 17:41 -0500, Matt McCutchen wrote:
> Instead,
> let's recommend daemon administrators to copy the necessary encoding
> helper libraries into the module and daemon-exclude them.
Ouch, this brings up a serious problem. Any writable chrooted module
that accepts
uested action not supported (code 4) at rsync.c(120)
> > > [receiver=3.0.0pre8]
> I already thought about that, but everything seems to work fine. I created a
> file with some umlauts in UTF-8 and converted it:
>
> $ iconv -f UTF-8 -t iso8859-15 -o test-iso-8859-15 test-utf8
On Saturday 09 February 2008 22:39, Matt McCutchen wrote:
> On Sat, 2008-02-02 at 14:00 +0100, Jochen Reinwand wrote:
> > I applied the patch to rsync-3.0.0pre8 and rsync-HEAD-20080127-2251GMT,
> > but the new setup_iconv doesn't seem to work. Trying to connect with
> >
On Sat, 2008-02-02 at 14:00 +0100, Jochen Reinwand wrote:
> I applied the patch to rsync-3.0.0pre8 and rsync-HEAD-20080127-2251GMT, but
> the new setup_iconv doesn't seem to work. Trying to connect with
> parameter --iconv set, the daemon writes the following to the syslog and
On Tue, Jan 29, 2008 at 10:00:06PM -0500, Matt McCutchen wrote:
> I put the call after the "if (write_batch < 0) dry_run = 1;" test, just
> as in main.
Thanks, Matt! This is now committed.
..wayne..
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posti
Sorry, didn't see the matching if statement. Commenting out the two lines
with ICONV in the config.h fixed my issue. Thanks...
Rob
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
On Tue, Feb 05, 2008 at 07:21:34PM -0700, Rob Bosch wrote:
> I tried changing the HAVE_ICONV_H and HAVE_ICONV_OPEN but this does
> not resolve the issue.
Comment both of them out in config.h.
> I noticed in rsync.c that there is an #endif without a matching if
> condition at the end of the iconvb
e
how the ic_chck = iconv_open(defset, defset); (line 83) can be impacted by
these options.
I have a feeling some of this is a function of the cygwin compile
environment that I'm using but it seems I should be able to define these
parameters as 0 and get rsync to compile without iconv.
R
On Sun, Feb 03, 2008 at 04:06:55PM -0700, Rob Bosch wrote:
> To bypass it I wanted to compile with the --disable-iconv function.
> I'm still getting the following errors during compile: [...]
The --disable-iconv configure option just disables the --iconv rsync
option. It does not disa
The error on 193 is due to the iconv reference in the while loop.Rob
/usr/src/rsync-3.0.0pre8/rsync.c:85: undefined reference to `_iconv_open'
rsync.o: In function `iconvbufs':/usr/src/rsync-3.0.0pre8/rsync.c:193:
undefined reference to `_iconv'/usr/src/rsync-3.0.0pre8/rsync.c
I've been trying to compile 3.0.0pre8 under cygwin. I was getting a problem
with the iconv functions which I think are related to the cygwin environment
and its iconv.h.
To bypass it I wanted to compile with the --disable-iconv function. I'm still
getting the following errors duri
Hi Matt,
thanks for the patch!
I applied the patch to rsync-3.0.0pre8 and rsync-HEAD-20080127-2251GMT, but
the new setup_iconv doesn't seem to work. Trying to connect with
parameter --iconv set, the daemon writes the following to the syslog and
closes the connection:
iconv_open(&
---
I put the call after the "if (write_batch < 0) dry_run = 1;" test, just
as in main. I think a single-use daemon will call both this setup_iconv
and the one in main, but I don't care: the one in main will have no
effect because the !am_server test will fail and the !iconv_opt return
will occur.
On Sat, 2007-12-15 at 23:36 +0100, Jochen Reinwand wrote:
> This one is NOT working (filenames are UTF-8 on target):
> $ rsync -av --iconv=utf-8,iso8859-15 test/ rsync://host/test
I can reproduce this with the current development rsync. It seems to be
caused by the accidental omissio
;MS Windows to stop this, but I don't use MS Windows to know for sure.
>
>Just to save people in the future searching, a link to a post that goes into a
>little detail about this problem is: -
>http://lists.samba.org/archive/rsync/2005-May/012638.html
>
>I use the hacked
re searching, a link to a post that goes
into a little detail about this problem is: -
http://lists.samba.org/archive/rsync/2005-May/012638.html
I use the hacked cygwin1.dll to work around it. I was hoping the iconv
flag would fix this issue, but its definitely more to do with the
interactio
On Thu, Jan 24, 2008 at 02:09:30PM +0900, Brendan Grieve wrote:
> I get the following error on files that have russian cryllic letters: -
> file has vanished: "/cygdrive/D/Data_Tier1/Home/xxx/??? "
See the prior discussions about how MS Windows is lying to rsync about
what the fil
---
Adding a hint about iconv --list is a good idea. This patch does it.
Matt
rsync.yo |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/rsync.yo b/rsync.yo
index 047e360..870993a 100644
--- a/rsync.yo
+++ b/rsync.yo
@@ -2015,7 +2015,8 @@ dit(bf(--iconv=CONVERT_SPEC
I have another question. I'm not sure if this is the correct post for
cygwin rsync related questions.
I've compiled rsync 3.0.0pre8 under cygwin. Works splendidly and
compiles cleanly. I made sure to have libiconv installed and it supports
the --iconv command (at least it accepts i
https://bugzilla.samba.org/show_bug.cgi?id=5162
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
this:
client charset: HEBREW
server charset: UTF-8
That will show you what the default_charset() function determined for the
transfer when using ".".
Since "HEBREW" worked for you (and indeed, worked fine for me too), this looks
like it may be an iconv library bug, but I&#x
https://bugzilla.samba.org/show_bug.cgi?id=5162
--- Comment #4 from [EMAIL PROTECTED] 2008-01-01 09:45 CST ---
I just readlized that specifying explicitly --iconv=HEBREW,UTF-8 solves the
issue.
So i guess the error is in the locale autodetection under cygwin and windows.
using
https://bugzilla.samba.org/show_bug.cgi?id=5162
--- Comment #3 from [EMAIL PROTECTED] 2008-01-01 08:49 CST ---
Created an attachment (id=3084)
--> (https://bugzilla.samba.org/attachment.cgi?id=3084&action=view)
Hebrew testcase
I'm not sure how to determine the locale charsets,
i gue
1 - 100 of 123 matches
Mail list logo
