similar to: rsync 3.0.9 hangs on large file

--- Erhalten von ZBM.ZARBR 089/32000-545 24-02-03 12.07 Hi, I mirror a server installation using rsync 2.5.6 (on both sides) with these options: -a -x --numeric-ids -H --delete --stats -e ssh -z --exclude-from ... This happens every night. In about 80% of the cases rsync returns exit status 12 when trying to transfer a certain file. In the other 20% the file is

OK. I got the rsync CVS code and compiled under Linux. That did the job, but only with --no-whole-file because of the local transfer. I then tried to read-batch... under Windows / Cygwin with the current Cygwin rsync. That didn't work - as expected. After compiling again under cygwin it worked! I can now create a diff from a new CD to the version before and send the diff files by email. On

I'm trying to rsync a very large (62gig) file from one machine to another as part of a nightly backup. If the file does not exist at the destination, it takes about 2.5 hours to copy in my environment. But, if the file does exist and --inplace is specified, and the file contents differ, rsync either is so significantly slowed as to take more than 30 hours (the longest I've let an

Hi! We (NetBSD pkgsrc) got the following bug report: http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=18134 In short, it says that rsync-2.5.5 does not bind to a IPv4 port (it binds only to an IPv6 port) when used with rsync --daemon, making it impossible to use rsync as rsync server under NetBSD 1.5.2 Any hints on this one? Also, one patch we have in pkgsrc seems not to have been

Hello, (Sorry, my english is no good) I've been searching for solutions but I don't find it. I'm using last version of cygwin (1.5.25-15) on Windows 2003 Server for transfer a Virtual Machine Backup (<2 GB .vmdk files; VCBMOUNTER) to a remote site with same rsync version. Sometimes this rsync task fails to transfer a file with compress (z) but doesn't fail without this

I recently became the new rsync maintainer for Red Hat, and I just completed a review of the current patches that we (Red Hat) maintain for 'rsync'. After removing three unnecessary patches (either already incorporated into rsync-2.5.6, or were outdated and couldn't be applied), we are left with one patch - rsync-2.5.6-sign.patch - which I have attached.

Everything worked, files transferred fine however a -vvv reveals that the process did not end clean. The error is not seen with -v or even -vv. Any insight? rsync version 2.5.5 protocol version 26, running on Solaris 8. Write failed flushing stdout buffer. write stdout: Broken pipe rsync error: unexplained error (code 255) at main.c(925) _exit_cleanup(code=255, file=main.c, line=925): about to

Greetings, I'd like to propose a new option to rsync, which causes it to read device files as if they were regular files. This includes pipes, character devices and block devices (I'm not sure about sockets). The main motivation is cases where you need to synchronize a large amount of data that is not available as regular files, as in the following scenarios: * Keep a copy of a block

--- common/mlpcre/PCRE.ml | 3 +-- common/mlpcre/PCRE.mli | 14 ++++++++++++++ common/mlpcre/pcre-c.c | 27 +++++++++++++++++++++++++++ common/mlpcre/pcre_tests.ml | 19 ++++++++++++++++--- 4 files changed, 58 insertions(+), 5 deletions(-) diff --git a/common/mlpcre/PCRE.ml b/common/mlpcre/PCRE.ml index 94eea4b34..5269d41f8 100644 --- a/common/mlpcre/PCRE.ml +++

https://bugzilla.samba.org/show_bug.cgi?id=7903 Summary: Cannot complete sync Product: rsync Version: 3.0.7 Platform: x64 OS/Version: Linux Status: NEW Severity: major Priority: P3 Component: core AssignedTo: wayned at samba.org ReportedBy: triune at gmail.com QAContact: rsync-qa

On Thu, 2016-10-13 at 20:08 -0400, Kevin Korb wrote: > I don't remember whether or not you said you were running rsync over > ssh but if you are you can also debug the ssh layer.  You can even do > it at both ends.... > > On the server run a debugging sshd on an alternate port with: > /usr/sbin/sshd -dDp222 > (note that this will only accept 1 connection, debug to the

On Wed, Jan 30, 2002 at 06:03:10PM -0500, Bill Nottingham wrote: > Dave Dykstra (dwd@bell-labs.com) said: > > I stumbled across the bug report > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=58878 > > > > which shows that you made a bug fix to rsync on Sunday. What exactly did > > you do? > > Attached. It's the same thing as yours, I just

Currently rsync has a bit of a problem with very large files. Dynamic block sizes were introduced to try handle that automatically if the user didn't specify a block size. Unfortunately that isn't enough and the block size would need to grow faster than the file. Besides, overly large block sizes mean large amounts of data need to be copied even for small changes. The maths indicate

hi there i'm trying to backup a 3gig directory with about 100.000 files from a windows pc to a linux box with rsync but the process stalls (hangs). setting a "--timeout 60" shows me that the i/o stalls. doing the same with smaller directories works perfectly but the whole 100.000 files seem to be too much. the process hangs before the file list is done. rsync doesn't start

Mark II of the patch set. The first patch (dynsumlen2.patch) increments the protocol version to support per-file dynamic block checksum sizes. It is a prerequisite for varsumlen2.patch. varsumlen2.patch implements per-file dynamic block and checksum sizes. The current block size calculation only applies to files between 7MB and 160MB setting the block size to 1/10,0000 of the file length for a

I don't remember whether or not you said you were running rsync over ssh but if you are you can also debug the ssh layer. You can even do it at both ends.... On the server run a debugging sshd on an alternate port with: /usr/sbin/sshd -dDp222 (note that this will only accept 1 connection, debug to the terminal, then exit) then on the client use rsync -e "ssh -vp222" to go verbose

https://bugzilla.samba.org/show_bug.cgi?id=2628 hmijail@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hmijail@gmail.com ------- Comment #12 from hmijail@gmail.com 2008-05-01 06:45 CST ------- Bitten here by what seems to be the same bug.

This way it is possible to change where the matching start, instead of always assuming it is the beginning. --- common/mlpcre/PCRE.ml | 2 +- common/mlpcre/PCRE.mli | 5 ++++- common/mlpcre/pcre-c.c | 16 +++++++++++++--- common/mlpcre/pcre_tests.ml | 11 ++++++++--- 4 files changed, 26 insertions(+), 8 deletions(-) diff --git a/common/mlpcre/PCRE.ml b/common/mlpcre/PCRE.ml

This way it is possible to change where the matching start, instead of always assuming it is the beginning. --- common/mlpcre/PCRE.ml | 2 +- common/mlpcre/PCRE.mli | 5 ++++- common/mlpcre/pcre-c.c | 16 +++++++++++++--- common/mlpcre/pcre_tests.ml | 15 ++++++++++++--- 4 files changed, 30 insertions(+), 8 deletions(-) diff --git a/common/mlpcre/PCRE.ml b/common/mlpcre/PCRE.ml

Hi! I try to use batch mode to send only the difference between two packed CDs by email over a slow line. I create the diff with: rsync -avvv --write-batch=rs CD-ROM-V6.6.32.zip CD-ROM-V6.6.31.zip where alfred:/Auslieferung/CD # l -n -rw-r--r-- 1 0 0 453248121 Sep 2 16:22 CD-ROM-V6.6.31.zip -rw-r--r-- 1 0 0 407416499 Sep 29 13:39 CD-ROM-V6.6.32.zip resulting