similar to: [patch] read-devices

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

> Just curious: what about the rsync+ patch? Thanks for the reminder. I've just committed Jos's rsync+ patch onto the "branch_mbp_rsyncplus_merge" branch. If it works OK and nobody screams I will move it across onto the main tree tomorrow or Wednesday. I see the patch doesn't add documentation about the new options to the man page, so we should fix that in the future.

Maybe security related mails should be sent elsewhere? I didn't notice any so here it goes: sender.c:receive_sums() s->count = read_int(f); .. s->sums = (struct sum_buf *)malloc(sizeof(s->sums[0])*s->count); if (!s->sums) out_of_memory("receive_sums"); for (i=0; i < (int) s->count;i++) { s->sums[i].sum1 = read_int(f);

Attached is a patch that makes window strides constant when files are walked with a constant block size. In these cases, it completely avoids all memmoves. In my simple local test of rsyncing 57MB of 10 local files, memmoved bytes went from 18MB to zero. I haven't tested this for a big variety of file cases. I think that this will always reduce the memmoves involved with walking a large

hi, I made some changes to generator.c : - reading data, calculating checksums and sending it to the sender now happens in one loop. - the code has become shorter - it uses less memory - 2 malloc's less that may fail - the line will be used all the time - it should be a bit faster It seems to work for me, please have a look at it. You should run "make proto" after

Hi, I think I found a bug in usage of zlib. rsync 2.5.6 with -z fails like bellow. % cp install-disk2.iso /var/tmp/install-disk2.iso install-disk2.iso 100% |*****************************| 316 MB 00:56 % rsync -vIz install-disk2.iso 127.0.0.1:/var/tmp/install-disk2.iso install-disk2.iso deflate on token returned 0 (16384 bytes left) rsync error: error in rsync protocol

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

In short: Platform: linux with 2.4 kernel Version: rsync 2.6.6 Command line: rsync266 -av -W --bwlimit=1 /mnt/somedir/rsync-2.6.6.tar.gz ./ Destination: local disk Source: file on a smbfs mounted filesystem; share is exported on a NT 4.0 workstation over a very slow and unstable link Result: Rsync completes operation with no special message, but the resulting file is damaged, large

Hi, I'm having a problem rsyncing one file (since I signed it). It seems that the content of a file is able to cause problems in the protocol. building file list ... 28820 files to consider apt/packages/avifile/ apt/packages/avifile/avifile-0.7.34-1.dag.rh90.i386.rpm rsync: error writing 4 unbuffered bytes - exiting: Broken pipe rsync error: error in rsync protocol data stream (code

Hi, I have compiled the new version 2.5.2 rsync in our servers, then ran rsync last night, there were some files not copied to destination server, both source and destination servers are running 2.5.2, I got the following error messages, can you please let me know what would be caused the errors? I copied back 2.3.2 version on both servers, and rsync went well. Thanks for the help, here is

I am trying to finalize the use of rsync for updatiung a new nfs server before we take the old one offline. I keep getting the following warning during the rsync process: Warning: unexpected rad size of 0 in map_ptr Any ideas where this comes from and how to make it go away? I am using rsync 2.5.2 on Solaris 8 to pull data from rsync 2.5.2 on Solaris 7. Bob roconnor@vectorpartners.com

Using OpenSSH 2.3.1 client and OpenSSL 0.9.6a When trying to ssh to OpenSSH server of higher versions SSH-1.99-OpenSSH_2.5.2p2 or such, I see error in RSA key exchange: RSA_verify(..)routine. I see: error at:int RSA_verify(int dtype, unsigned char *m, unsigned int m_len, unsigned char *sigbuf, unsigned int siglen, RSA *rsa) { int i,ret=0,sigtype; unsigned char *p,*s;

https://bugzilla.samba.org/show_bug.cgi?id=8177 Summary: Problems with big sparsed files Product: rsync Version: 3.0.8 Platform: x64 OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: joluinfante at gmail.com

Hi, When using rsync-3.0.2 through 3.0.5, I get this error on a large dataset syncing from machine-a to machine-b: $ /bin/rsync -aHSz /local/. machine-b:/local/. invalid len passed to map_ptr: -1737287498 rsync error: error in file IO (code 11) at fileio.c(188) [sender=3.0.5] This happens no matter which side initiates the connection, so this fails in the same way: $ /bin/rsync -aHSz

We're using rsync to mirror a web server. The rsync is initiated using ssh from a Red Hat Linux 7.2 box, the files are located on an Alpha running a version of Digital Unix 4. On the Alpha rsync is 2.5.2, The Linux box used to have a 2.4.6-X version, but with the map_ptr problems I built 2.5.2 on that as well. However, version incompatibility was not the problem, as they persist after the

https://bugzilla.samba.org/show_bug.cgi?id=9894 Summary: Rsync can silently zero out chunks in a file Product: rsync Version: 3.0.9 Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: an.m at outlook.com

https://bugzilla.samba.org/show_bug.cgi?id=6293 Summary: rsync crashes when transferring files Product: rsync Version: 3.0.5 Platform: x86 OS/Version: Mac OS X Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: dirk.samba@miriup.de

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

Further pursuing my curiosity to measure the efficiency of R/C++ interface, I conducted a simple matrix-vector multiplication test using .C and .Call functions in R. In each case, I measured the execution time in R, as well as inside the C++ function. Subtracting the two, I came up with a measure of overhead associated with each call. I assume that this overhead would be non-existent of the entire

I'm in the midst of coding a patch set for consideration that will bump the protocol version and have a couple of observations. The current minimum backwards-compatible protocol is 15 but we have code that checks for protocol versions as old as 12. If someone else doesn't beat me to it i'm considering cleaning out the pre-15 compatibility code. A backwards compatibility patch could