similar to: Rsync performance increase through buffering

Author of the message didn't include rsync@lists.samba.org in the reply, and I think this message is in topic. -------- Original Message -------- Subject: Re: rsync windows -> unix still hanging :( Date: Mon, 30 Dec 2002 16:10:32 -0800 From: Jim Kleckner <jek-cygwin@kleckner.net> To: Mike Rubel <mrubel@galcit.caltech.edu>, cygwin@cygwin.com Mike - Greger Cronquist and I

Author of the message didn't include rsync@lists.samba.org in the reply, and I think this message is in topic. -------- Original Message -------- Subject: Re: rsync windows -> unix still hanging :( Date: Mon, 30 Dec 2002 17:24:47 -0800 From: Jim Kleckner <jek_subs@kleckner.net> To: Mike Rubel <mrubel@galcit.caltech.edu> CC: cygwin@cygwin.com References:

Platform: Compaq OpenVMS Alpha 7.3 Compiler: Compaq C T6.5 The following patch resolves compile problems with the IO.C module. The (char) type was being used where (void) was more appropriate based on the actual use of the code. The (char) type was also being used where the usage was actually an (unsigned char). const qualifiers were added to improve compile efficiency. EAGLE> type

Hi, In http://sources.redhat.com/ml/cygwin/2002-09/msg01155.html, I noted that the often-observed hangs of rsync under Cygwin were assuaged by a call to msleep(). After upgrading my Cygwin environment to rsync 2.5.6, I'm seeing these hangs again, not surprisingly given a CVS entry for main.c notes that this kludge was not harmless: Revision 1.162 / (download) - annotate - [select for

tridge and Wayne in particular: I checked in this patch, which is meant to consolidate the ones from both of you for handling EOF in a modules list. The idea is that we need to handle servers that just close the socket rather than sending a nice ending token, but we want to keep EOF detection on in general. (The IO code is such a mess!) -- Martin Index: clientserver.c

Hello everyone! I didn't find anything in the archives that seemed similar (same error, different offending lines of code). I'm having an issue with rsync on a couple of my servers. A couple of others run just fine but 2 of them give me the same message (see below) when I try to do backups from one server to these linux boxes. All of the linux boxes are the same and have the save

Rsync list: Alberto and I have done a couple more exchanges by private email, and we found that he wasn't turning on my include/exclude optimization in his test because he had an "exclude" directive in rsyncd.conf. He has now removed that and run the test again. His very interesting results are below with my comments. Note that his case is rather pathological because he's got

Note: stub out endian-ness conversion for now. We'll add a flag to control it for BE guests later. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- This will be needed once __virtio16 typedefs come in. drivers/net/tun.c | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index

Note: stub out endian-ness conversion for now. We'll add a flag to control it for BE guests later. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- This will be needed once __virtio16 typedefs come in. drivers/net/tun.c | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index

Yes, it's time once again to return to the subject of moving files. With the recent changes to the communications code between the receiver and the generator, there is now a non-clogging channel that we can use to signal the sender when a file has been successfully transferred, which allows us delete the original for all transferred files. I have in the past waffled on whether this feature

When I was working on the the hard-link change, I noticed that many of the hard-link verbose messages were getting lost. These messages get output very near the end of the transfer, and it turns out that the reason for the loss was that there are two pipes flowing from the generator and the receiver, and it was possible for the "we're all done" message to get received down the redo

This patch introduces to a new tun/tap specific msg_control: #define TUN_MSG_UBUF 1 #define TUN_MSG_PTR 2 struct tun_msg_ctl { int type; void *ptr; }; This allows us to pass different kinds of msg_control through sendmsg(). The first supported type is ubuf (TUN_MSG_UBUF) which will be used by the existed vhost_net zerocopy code. The second is XDP buff, which allows vhost_net to

Initial problem: When running 'make test' the hands.test fails as indicated in problem #3711 and includes the line rsync error: unexplained error (code 63) at main.c(537) The code # changes each time the test is run. Using HP C-ANSI-C B.11.11.02. configure line: CFLAGS="-O" ./configure --prefix=/opt/local In tracking this down, this is what I found: In main.c a

On Thu, Sep 06, 2018 at 12:05:23PM +0800, Jason Wang wrote: > This patch introduces to a new tun/tap specific msg_control: > > #define TUN_MSG_UBUF 1 > #define TUN_MSG_PTR 2 > struct tun_msg_ctl { > int type; > void *ptr; > }; > > This allows us to pass different kinds of msg_control through > sendmsg(). The first supported type is ubuf

Wayne, Please consider the attached patch. This applies to the current CVS, and is independant of patches/local-batch.diff. As a matter of fact, I'm sure it would conflict heavily with local-batch.diff. This version of batch mode has a couple distinguishing features: Write-batch records (almost) the entire sender side of the conversation into one file. ("Almost" because it has

https://bugzilla.samba.org/show_bug.cgi?id=4139 Summary: Generator process (running as daemon) hangs after kill SIGINT. Product: rsync Version: 2.6.8 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org

https://bugzilla.samba.org/show_bug.cgi?id=5020 Summary: hang using RSYNC_CONNECT_PROG Product: rsync Version: 3.0.0 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: Matt_Domsch@dell.com QAContact:

[This is a copy of the contents of Debian bug report #147842.] Package: rsync Version: 2.5.5-0.2 Severity: normal Cause ----- - rsync forks a child which in turn forks a grandchild in main.c:do_recv(). - Diagnostics written by the grandchild need to be read by the child using read_error_fd() to be handled properly (with the end result being that they are seen by the user running rsync). -

Hey guys, I've been working with rsync for the last couple weeks and I really need some help here. Linux to Linux transfers are working beautifully, but for the life of me I can't get transfers from win2k to work. I have the exact problem that was reported by Mark de Jong on Tue, 16 Jul 2002. I'm using the lastest version of cygwin, with rsync 2.5.5 and ssh 3.5p1 for my tests. The

rsync 2.5.0 still has a bug where it hangs under some circumstances. The hang is beyond my abilities to track down. I'll keep trying, though, but here are details in case they're of use to anyone else: - Code configured & built on Solaris 2.5.1. - Same binary run on Solaris 2.5.1 (client) and 2.8 (server). - Using rsh transport, but also fails with ssh - Does not fail with