source-filter_dest-filter patch failing with rsync 3.0.0

I'm using the source-filter option in this patch with the command rsync.exe -a -v -e ssh --source-filter="/cygdrive/c/openssl.exe enc -des3 -pass pass:whatever -a" /cygdrive/c/backup [EMAIL PROTECTED]: to crypt files to be sent at source with openssl. At some point rsync fails an i get 104435520 [

Re: Issue with rsync 3.0.0 and iconv

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

Re: Issue with rsync 3.0.0 and iconv

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

Re: Issue with rsync 3.0.0 and iconv

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

Re: Issue with rsync 3.0.0 and iconv

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

Re: Issue with rsync 3.0.0 and iconv

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

Re: Issue with rsync 3.0.0 and iconv

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

Issue with rsync 3.0.0 and iconv

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 (Debian) to 3

rsync 3.0.0

I know I'm late to the party, but I just had my first encounter with rsync 3 and ... wow ! I'm using rsync to perform local backups to an external USB hard drive. This is on a (slow) P3 running Debian Lenny. So... [EMAIL PROTECTED]:~$ sudo rsync -av /home /media/disk/ --delete !?! Hey - it'

DO NOT REPLY [Bug 5309] double free or corruption while using rsync 3.0.0 stable

https://bugzilla.samba.org/show_bug.cgi?id=5309 --- Comment #4 from [EMAIL PROTECTED] 2008-03-15 02:48 CST --- Created an attachment (id=3174) --> (https://bugzilla.samba.org/attachment.cgi?id=3174&action=view) Fixed a crash bug in the backup code This patch allocate room for a dir'

DO NOT REPLY [Bug 5309] double free or corruption while using rsync 3.0.0 stable

https://bugzilla.samba.org/show_bug.cgi?id=5309 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|

RE: (cw)rsync 3.0.0 incompatible with 2.6.9

13. mars 2008 03:39 > To: Mojca Miklavec > Cc: rsync@lists.samba.org; Tevfik Karagülle; Taco Hoekwater > Subject: Re: (cw)rsync 3.0.0 incompatible with 2.6.9 > > On Wed, 2008-03-12 at 20:57 +0100, Mojca Miklavec wrote: > > On Wed, Mar 12, 2008 at 4:46 PM, Matt McCutchen wro

Re: (cw)rsync 3.0.0 incompatible with 2.6.9

On Wed, 2008-03-12 at 20:57 +0100, Mojca Miklavec wrote: > On Wed, Mar 12, 2008 at 4:46 PM, Matt McCutchen wrote: > > 3. Have cwRsync 3.0.0 users pass RSYNC_ICONV=- or --no-iconv . > > That's what has been suggested by Tevfik Karagülle, but it's ugly as > it cannot be written in a portable way. (

Re: (cw)rsync 3.0.0 incompatible with 2.6.9

Debian stable, so sooner or later people will > > start using the new incompatible version before we upgrade the system. > > Is manual install of a newer version of rsync on the server really the > > only option? > > I can think of four options: > > 1. Replace

RE: (cw)rsync 3.0.0 incompatible with 2.6.9

On Wed, 2008-03-12 at 17:11 +0100, Tevfik Karagülle wrote: > I am a little bit confused now. What's best ? An rsync with iconv enabled or > not ? > > I thought that iconv support could be useful to handle file names with > foreign characters. However, I see now that an iconv-enabled rsync has som

Re: (cw)rsync 3.0.0 incompatible with 2.6.9

eplace the server's current rsync with a manually installed rsync 3.0.0. 2. Install rsync 3.0.0 in a non-default location and have cwRsync 3.0.0 users request it via --rsync-path. 3. Have cwRsync 3.0.0 users pass RSYNC_ICONV=- or --no-iconv . 4. Build your own Cygwin rsync (which will h

(cw)rsync 3.0.0 incompatible with 2.6.9

Hello, This seems like rather serious issue to me. I have updated the windows binary for rsync to 3.0.0 (cwrsync), and now I get the following error: receiving file list ... rsync: on remote machine: --iconv=.: unknown option rsync error: requested action not supported (code 4) at clientserver.c

Re: Rsync 3.0.0 universal binary availible?

Hi All, So far the tests show the universal build of rsync 3.0 (using lipo) to be indeed universal. Metadata tests all come up clean on OSX Tiger and Leopard, both PPC and Intel architectures. Some people asked for the compiled binary so I put it here: http://rdutoit.home.comcast.net/~r

DO NOT REPLY [Bug 5309] double free or corruption while using rsync 3.0.0 stable

https://bugzilla.samba.org/show_bug.cgi?id=5309 --- Comment #2 from [EMAIL PROTECTED] 2008-03-10 06:13 CST --- strange: if I compile rsync with "enable maintainer mode" and run the rsync -client as root from bash, after the crash it tells me "xterm ...: Can´t open display" for some m

DO NOT REPLY [Bug 5309] double free or corruption while using rsync 3.0.0 stable

https://bugzilla.samba.org/show_bug.cgi?id=5309 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from [EM

DO NOT REPLY [Bug 5309] New: double free or corruption while using rsync 3.0.0 stable

https://bugzilla.samba.org/show_bug.cgi?id=5309 Summary: double free or corruption while using rsync 3.0.0 stable Product: rsync Version: 3.0.0 Platform: x64 OS/Version: Linux Status: NEW Severity: normal Priority

Re: Rsync 3.0.0 and Mac OS X

Linus, On Wed, 2008-03-05 at 23:21 +0100, Linus Neumann wrote: > I read your "rsync on Mac" Discussion dated January 2008. > I would be very thankful if you could help me with the exact same > problem. This kind of message should go to the rsync list for archival even if you have a good guess of

Re: rsync 3.0.0 apparently crashing when running a single-use "daemon" server process

On Tue, Mar 04, 2008 at 06:20:21PM +0100, Paul Slootman wrote: > The other issue in the bug report is something else, but as that happens > when using 3.0.0 going to the 2.6.8 version running at rsync.net It sounds like they're running something like the support/rrsync validation script, which rem

DO NOT REPLY [Bug 5301] rsync 3.0.0 copyright dates not updated to 2008

https://bugzilla.samba.org/show_bug.cgi?id=5301 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

Re: rsync 3.0.0 apparently crashing when running a single-use "daemon" server process

On Mon 03 Mar 2008, Wayne Davison wrote: > On Mon, Mar 03, 2008 at 01:50:28PM -0800, Wayne Davison wrote: > > I'll fix the NULL and look to get a test for this added. > > The git repository has both the fix and the extended test. > > Attached is just the NULL-pointer fix. Confirmed that it now w

Re: rsync 3.0.0 apparently crashing when running a single-use "daemon" server process

On Mon, Mar 03, 2008 at 01:50:28PM -0800, Wayne Davison wrote: > I'll fix the NULL and look to get a test for this added. The git repository has both the fix and the extended test. Attached is just the NULL-pointer fix. Thanks for your help! ..wayne.. --- a/clientserver.c +++ b/clientserver.c @

Re: rsync 3.0.0 apparently crashing when running a single-use "daemon" server process

On Mon, Mar 03, 2008 at 09:16:46PM +0100, Paul Slootman wrote: > The short story: it looks like client_info is NULL at compat.c:90, if I > look at the strace and ltrace output supplied in the above URL. No, looks like the problem is a NULL config_file var. If rsync had been called with --rsync-pa

rsync 3.0.0 apparently crashing when running a single-use "daemon" server process

The long story: http://bugs.debian.org/469172 The short story: it looks like client_info is NULL at compat.c:90, if I look at the strace and ltrace output supplied in the above URL. Perhaps someone can investigate further, I don't have much time this evening. Tomorrow I can look again Paul

DO NOT REPLY [Bug 5301] rsync 3.0.0 copyright dates not updated to 2008

https://bugzilla.samba.org/show_bug.cgi?id=5301 --- Comment #1 from [EMAIL PROTECTED] 2008-03-03 09:57 CST --- Created an attachment (id=3158) --> (https://bugzilla.samba.org/attachment.cgi?id=3158&action=view) Update copyright in options.c -- Configure bugmail: https://bugzilla.s

DO NOT REPLY [Bug 5301] New: rsync 3.0.0 copyright dates not updated to 2008

https://bugzilla.samba.org/show_bug.cgi?id=5301 Summary: rsync 3.0.0 copyright dates not updated to 2008 Product: rsync Version: 3.0.0 Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P3

RE: Rsync 3.0.0 released

A new version of cwrsync including rsync 3.0.0 is now available from http://itefix.no/cwrsync Tev > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Wayne Davison > Sent: 1. mars 2008 22:30 > To: [EMAIL PROTECTED] > Cc:

Re: Rsync 3.0.0 released

On Sat, 2008-03-01 at 13:29 -0800, Wayne Davison wrote: > Yes, it's finally that time -- rsync 3.0.0 has been released. This is a > feature release that also includes quite a few bug fixes. > > I'd like thank everyone who participated in the development and testing > o

Re: Rsync 3.0.0 released

Le samedi 01 mars 2008, Wayne Davison a écrit : > Yes, it's finally that time -- rsync 3.0.0 has been released. This is a > feature release that also includes quite a few bug fixes. Rsync 3.0.0 is already provide in mandriva cooker and will included in 2008.1 which should be releas

Re: Rsync 3.0.0 released

still is) accurate (for those that looked there): http://rsync.samba.org/ftp/rsync/rsync-3.0.0-NEWS ..wayne.. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Rsync 3.0.0 released

On Sat, Mar 01, 2008 at 04:58:04PM -0500, Matt McCutchen wrote: > On Sat, 2008-03-01 at 13:29 -0800, Wayne Davison wrote: > > Yes, it's finally that time -- rsync 3.0.0 has been released. This is a > > feature release that also includes quite a few bug fixes. > > >

Re: Rsync 3.0.0 released

My congrats ! I agree this is the right decision at this stage. The link to the changes since 2.6.9 did not work. As far as i can see, the file is missing on the server. Greetz, Nico Wayne Davison schreef: Yes, it's finally that time -- rsync 3.0.0 has been released. This is a fe

Re: Rsync 3.0.0 released

On Sat, 2008-03-01 at 13:29 -0800, Wayne Davison wrote: > Yes, it's finally that time -- rsync 3.0.0 has been released. This is a > feature release that also includes quite a few bug fixes. > > I'd like thank everyone who participated in the development and testing > o

Rsync 3.0.0 released

Yes, it's finally that time -- rsync 3.0.0 has been released. This is a feature release that also includes quite a few bug fixes. I'd like thank everyone who participated in the development and testing of rsync. I hope that you enjoy this latest version! The 3.0.0 version number

Re: --suffix-dels unknown option on in rsync 3.0.0.

On Wed, 2008-02-06 at 17:24 +0100, Olivier Thauvin wrote: > I am trying to run: > > rsync --dry-run -avz --force --no-whole-file -e "ssh -C" --delete > --bwlimit=35 > \ > --backup --exclude "*.backup-*" --exclude "*:*" > '--suffix'=.backup-`date > +%m%d` \ > /mnt/unite-c/ [EM

--suffix-dels unknown option on in rsync 3.0.0.

I am trying to run: rsync --dry-run -avz --force --no-whole-file -e "ssh -C" --delete --bwlimit=35 \ --backup --exclude "*.backup-*" --exclude "*:*" '--suffix'=.backup-`date +%m%d` \ /mnt/unite-c/ [EMAIL PROTECTED]:~/unite-c/ But I get: rsync: on remote machine: --suffix-del

Re: rsync 3.0.0 pre5 + hard link preversation trigger assert

Le mercredi 30 janvier 2008, Matt McCutchen a écrit : > On Mon, 2007-11-12 at 20:08 +0100, Olivier Thauvin wrote: > > I've setup rsync 3.0.0 pre5 on distrib-coffee.ipsl.jussieu.fr (rsync > > server) and upload the same into mandriva cooker (development > > distribution

Re: rsync 3.0.0 pre5 + hard link preversation trigger assert

On Mon, 2007-11-12 at 20:08 +0100, Olivier Thauvin wrote: > I've setup rsync 3.0.0 pre5 on distrib-coffee.ipsl.jussieu.fr (rsync server) > and upload the same into mandriva cooker (development distribution). > I was trying to see what happend (I am unable to reproduce) when I tri

rsync 3.0.0 pre5 + hard link preversation trigger assert

I've setup rsync 3.0.0 pre5 on distrib-coffee.ipsl.jussieu.fr (rsync server) and upload the same into mandriva cooker (development distribution). Someone reported this failure: rsync -auvPH --delete --exclude-from="/home/rfox/exclude.txt" distrib-coffee.ipsl.jussieu.fr::mand

Re: Milestone release for rsync 3.0.0?

On 9/3/07, Wayne Davison <[EMAIL PROTECTED]> wrote: > I'm hoping that it won't be all that much longer before the first > pre-release version will be ready. I mainly want to get hard-link > support working in incremental recursion mode (which is getting pretty > close in my local copy), and to fix

Re: Milestone release for rsync 3.0.0?

On Sun 02 Sep 2007, Wayne Davison wrote: > > I'm hoping that it won't be all that much longer before the first > pre-release version will be ready. I mainly want to get hard-link > support working in incremental recursion mode (which is getting pretty Hmm, I would have found it acceptable to del

Re: Milestone release for rsync 3.0.0?

On Thu, Aug 30, 2007 at 05:11:18PM -0400, Matt McCutchen wrote: > Rsync 3.0.0 has been under development for 8 months now, but its final > release still appears to be a very long way off I'm hoping that it won't be all that much longer before the first pre-release version will be

Milestone release for rsync 3.0.0?

Wayne, Rsync 3.0.0 has been under development for 8 months now, but its final release still appears to be a very long way off, and at least one person has expressed interest in having a copy of rsync 3.0.0 to try out ( http://lists.samba.org/archive/rsync/2007-February/017372.html ). I encourage

Re: Might hanging bugs remain in rsync 3.0.0?

On Jul 16, 2007, at 8:55 AM, Matt McCutchen wrote: Instead of making users scratch their heads when something goes wrong, I think it would be prudent to make --no-ir the default in rsync 3.0.0. (I'm afraid that if you don't, some distributions might.) Users who care about th

RE: Might hanging bugs remain in rsync 3.0.0?

ential bugs than in previous versions. > > > And the user will > > always have the option of specifying --no-ir if they need to. > > I don't like this logic; rsync should work by default. > Instead of making users scratch their heads when something > goes wro

Re: Might hanging bugs remain in rsync 3.0.0?

least there are more potential bugs than in previous versions. And the user will always have the option of specifying --no-ir if they need to. I don't like this logic; rsync should work by default. Instead of making users scratch their heads when something goes wrong, I think it would be p

Re: Might hanging bugs remain in rsync 3.0.0?

On Sun, Jul 15, 2007 at 11:09:57PM -0400, Matt McCutchen wrote: > Furthermore, from April 27 to July 10, about 2.5 months passed without > any hanging bugs being found; then, on July 11, Warren Oates reported > one. That was a brand new one that I introduced into the code when I tweaked the index

Might hanging bugs remain in rsync 3.0.0?

Wayne, I am concerned that, when you decide to release rsync 3.0.0, one or more hanging bugs may remain in the incremental recursion code. My rationale is as follows. At least four such bugs have been found so far, and I see no evidence that those are all there are. Furthermore, from April 27

rsync 3.0.0

Hi All Any idea when the 3.0.0 will be rolled out? Thanks! -- Ming Zhang @#$%^ purging memory... (*!% http://blackmagic02881.wordpress.com/ http://www.linkedin.com/in/blackmagic02881 -- To unsubscribe or change options: https://lists.samba.org/mai

Re: Rsync 3.0.0 report and a performance question.

During more testing along your suggestions I realized that I had included the rotation of my backup trees in my rsync timing. Turns out the rm -r command to delete the oldest back tree was taking the most time (9 out of 12-14 min). This begs the question if one cannot recycle the oldest backu

Re: Rsync 3.0.0 report and a performance question.

On Fri, Feb 09, 2007 at 01:57:22PM -0800, Wayne Davison wrote: > If there are a large number of files to transfer, the win won't > really be that much, as the generator will be waiting around for new > file-list info a lot, and that data channel will be clogged up with > file data. In this context

Re: Rsync 3.0.0 report and a performance question.

On Mon, Feb 05, 2007 at 05:06:31PM -0800, Matt wrote: > Anyway, I am wondering why it is taking full 12 minutes to complete the > rsync. There are several things to check. Try timing an rsync run with -n to see how quickly it runs without doing any data transfer. Try doing an rsync of the destin

Re: Rsync 3.0.0 report and a performance question.

Sorry for being so persistent Even with non-incremental file list generation (protocol=29) I get a file list generation time of 80 sec but rsync still needs 12 min to finish with (almost) no data to transfer. What is it doing the other 10 min? ... Matt Paul Slootman wrote: > On Wed 07 Fe

Re: Rsync 3.0.0 report and a performance question.

On Wed 07 Feb 2007, Matt wrote: > Using --whole-file doesn't help, see below. BTW, rsync needs about the > same time even if no file has changes at all. It must be the > comparison of the file metadata. A rate 325 files/sec seems somewhat low > to me but maybe its mostly the time to read all di

Re: Rsync 3.0.0 report and a performance question.

Using --whole-file doesn't help, see below. BTW, rsync needs about the same time even if no file has changes at all. It must be the comparison of the file metadata. A rate 325 files/sec seems somewhat low to me but maybe its mostly the time to read all directories and the "File list generation t

Re: Rsync 3.0.0 report and a performance question.

On Mon 05 Feb 2007, Matt wrote: > > Anyway, I am wondering why it is taking full 12 minutes to complete the > rsync. The connection link is a GigE LAN. Thus most time is spent > comparing the file lists at sender and receiver. However, a comparison > rate of 217293 files / 670 sec = 325 files

Rsync 3.0.0 report and a performance question.

Hi, first a short success report: rsync 3.0.0 works as far as I can tell flawless for me. My performance question: Below are of some recent backup stats one, using the old protocol (29), the other the latest cvs (30). As you see, the file creation time has dropped significantly (0.01 sec vs

Re: using rsync 3.0.0 CVS version

On Tue 30 Jan 2007, Paul Slootman wrote: > Still going strong :) Still running ;) One note: don't forget to fix the copyright notice on rsync, s/2006/2007/ : # rsync --version rsync version 3.0.0cvs protocol version 30 Copyright (C) 1996-2006 by Andrew Tridgell, Wayne Davison, and others.

Re: using rsync 3.0.0 CVS version

On Tue 30 Jan 2007, Wayne Davison wrote: > On Tue, Jan 30, 2007 at 02:38:42PM +0100, Paul Slootman wrote: > > It also did the sync in under 2 hours, whereas the non-incremental > > version would take up to 12 hours, and use up to 500MB of memory. > > Awesome! That's an even more dramatic improvem

Re: using rsync 3.0.0 CVS version

On Tue, Jan 30, 2007 at 05:21:35PM +0200, Shai wrote: > Same here. I did my initial test and where before it used to hang, it > doesn't now :) Thanks for the update! I appreciate your help in the testing. If you have any speed comparisons between old and new rsync runs for your setup (approximat

Re: using rsync 3.0.0 CVS version

On Tue, Jan 30, 2007 at 02:38:42PM +0100, Paul Slootman wrote: > It also did the sync in under 2 hours, whereas the non-incremental > version would take up to 12 hours, and use up to 500MB of memory. Awesome! That's an even more dramatic improvement than what I was anticipating for large hierarch

Re: using rsync 3.0.0 CVS version

Same here. I did my initial test and where before it used to hang, it doesn't now :) Thanks for tonight's update! Shai On 1/30/07, Paul Slootman <[EMAIL PROTECTED]> wrote: On Mon 29 Jan 2007, Wayne Davison wrote: > On Mon, Jan 29, 2007 at 06:33:19PM +0100, Paul Slootman wrote: > > Unfortunate

Re: using rsync 3.0.0 CVS version

On Mon 29 Jan 2007, Wayne Davison wrote: > On Mon, Jan 29, 2007 at 06:33:19PM +0100, Paul Slootman wrote: > > Unfortunately the current CVS version (updated a couple of hours ago) > > still hangs :( > > I found another potential hang scenario that could happen if the > generator was having to wait

Re: using rsync 3.0.0 CVS version

On Mon, Jan 29, 2007 at 06:33:19PM +0100, Paul Slootman wrote: > Unfortunately the current CVS version (updated a couple of hours ago) > still hangs :( I found another potential hang scenario that could happen if the generator was having to wait for a new file list to arrive, but failed to tell th

Re: using rsync 3.0.0 CVS version

On Mon, Jan 29, 2007 at 06:33:19PM +0100, Paul Slootman wrote: > Just now, with various straces running, the sending process got to: The important process in the generator, since it controls all the work. (It is the first process on the receiving side, and forks the receiver). Attaching to the gen

Re: using rsync 3.0.0 CVS version

On Sat 27 Jan 2007, Wayne Davison wrote: > I had not encountered this hang until today. The backtrace implicated > a problem in the wait_for_receiver() routine, and I figured out that > every now and then the io_flush() call could end up reading the last > available message from the receiver, giv

Re: using rsync 3.0.0 CVS version

Sweet! I'll test it soon! On 1/27/07, Wayne Davison <[EMAIL PROTECTED]> wrote: On Sun, Jan 21, 2007 at 08:43:56AM +0200, Shai wrote: > When I start the rsync, either with the rsync protocol or rsh, i found > that it'll start doing the rsync and just halt after a few hundred MBs > or even up to

Re: using rsync 3.0.0 CVS version

On Sun, Jan 21, 2007 at 08:43:56AM +0200, Shai wrote: > When I start the rsync, either with the rsync protocol or rsh, i found > that it'll start doing the rsync and just halt after a few hundred MBs > or even up to a couple GBs. I had not encountered this hang until today. The backtrace implicat

Re: using rsync 3.0.0 CVS version

Any updates on this hanging issue being fixed? On 1/23/07, Paul Slootman <[EMAIL PROTECTED]> wrote: On Mon 22 Jan 2007, Paul Slootman wrote: > > It's the same binary, compiled from rsync-HEAD-20070120-2211GMT. I tried again with current cvs (with the 1.194 version of receiver.c), and it still

Re: using rsync 3.0.0 CVS version

On Mon 22 Jan 2007, Paul Slootman wrote: > > It's the same binary, compiled from rsync-HEAD-20070120-2211GMT. I tried again with current cvs (with the 1.194 version of receiver.c), and it still hangs when transferring an empty directory (it is created on the receiver though). A local transfer (r

Re: using rsync 3.0.0 CVS version

On Mon 22 Jan 2007, Wayne Davison wrote: > On Mon, Jan 22, 2007 at 10:04:10PM +0100, Paul Slootman wrote: > > This was to another system, over Gbit ethernet; both sides are amd64, > > running in 64 bits mode. > > Make sure that both sides are running the exact same code for protocol > 30 (because

Re: using rsync 3.0.0 CVS version

On Mon, Jan 22, 2007 at 10:04:10PM +0100, Paul Slootman wrote: > This was to another system, over Gbit ethernet; both sides are amd64, > running in 64 bits mode. Make sure that both sides are running the exact same code for protocol 30 (because the protocol is still in flux). If one side is older

Re: using rsync 3.0.0 CVS version

On Mon 22 Jan 2007, Matt McCutchen wrote: > I can't reproduce this hang in the current rsync from CVS. I tried > pushing an empty directory to a daemon on the same machine, but rsync > finished successfully. This was to another system, over Gbit ethernet; both sides are amd64, running in 64 bits

Re: using rsync 3.0.0 CVS version

On 1/22/07, Paul Slootman <[EMAIL PROTECTED]> wrote: I just noticed that rsync-HEAD-20070120-2211GMT will hang when transferring an empty directory: I can't reproduce this hang in the current rsync from CVS. I tried pushing an empty directory to a daemon on the same machine, but rsync finished

Re: using rsync 3.0.0 CVS version

On Sun 21 Jan 2007, Wayne Davison wrote: > Another thing you can do in the debugger when attached to the generator > is to output a summary of the file-list info: > > p *first_flist > p *first_flist->next > p *first_flist->next->next I just noticed that rsync-HEAD-20070120-2211GMT will hang when

Re: using rsync 3.0.0 CVS version

On 1/21/07, Wayne Davison <[EMAIL PROTECTED]> wrote: I'm thinking that I will add a debug-output signal handler, probably listening on SIGALRM. This will let the user kill -14 any rsync 3.0.0 process to have it mention its role and some debug info. I like this idea! Matt -- To uns

Re: using rsync 3.0.0 CVS version

en attached to the generator is to output a summary of the file-list info: p *first_flist p *first_flist->next p *first_flist->next->next I'm thinking that I will add a debug-output signal handler, probably listening on SIGALRM. This will let the user kill -14 any rsync 3.0.0 pr

Re: using rsync 3.0.0 CVS version

On 1/21/07, Shai <[EMAIL PROTECTED]> wrote: I've wanted to start working with this CVS version cuz the new "incremental-recursion algorithm" is just what I need. But ran into a problem... When I start the rsync, either with the rsync protocol or rsh, i found that it'll start doing the rsync and

using rsync 3.0.0 CVS version

Hi, I've wanted to start working with this CVS version cuz the new "incremental-recursion algorithm" is just what I need. But ran into a problem... When I start the rsync, either with the rsync protocol or rsh, i found that it'll start doing the rsync and just halt after a few hundred MBs or eve