similar to: why variable last_i is needed in match.c rsync source ?

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);

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

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

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

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.

I am trying to understand how match.c works. I am reading the code and something doesnt look quite right. This is usually a sign that I am missing something obvious. Here is what I see. build_hash_table uses qsort to order targets in ascending order of //tag,index// into the array of checksums. It then accesses the targets in ascending order and writes the index at the tag's location in

The match.c code has a loop that initializes an array to -1. I'm considering changing this to a memset() of 0xFF over all the array's bytes, but that depends on a system's representation of a -1 being "all bit on". Should I be anal about this and add a configure check to make sure that we're not running on some weird system where this is not true? Or should I just let

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

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 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

Wayne, It's taken a little while for me to get more familiar with the code, but I think I've reached a good breakpoint in improving batch-mode. Let me highlight some of the changes in the attached patch: * --write-batch and --read-batch arguments are no longer passed from client to server. This fixes the current problem that causes the server threads to die when the client

https://bugzilla.samba.org/show_bug.cgi?id=1467 ------- Additional Comments From ripper@internode.on.net 2004-06-19 02:18 ------- The way the code seems to work is as follows: A sorted list of hashes and their block numbers are generated (targets). They're sorted so that identical hashes are numerically next to each other. A reverse lookup table is then generated, that (i presume) is

Hi , > df Session_Setup DCT FwdDataVols_bin counts Comp 1 User_Initiated NoRLL 1 5058 User_Initiated+NoRLL+1 2 User_Initiated NoRLL 2 584 User_Initiated+NoRLL+2 3 User_Initiated NoRLL 3 191 User_Initiated+NoRLL+3 4 User_Initiated NoRLL 4 128 User_Initiated+NoRLL+4 5 User_Initiated

Df contains Session_Setup DCT RevDataVols_bin counts comp 1 Session_Setup RLL 1 NA Session_Setup+RLL+1 2 Session_Setup RLL 2 NA Session_Setup+RLL+2 3 Session_Setup RLL 3 NA Session_Setup+RLL+3 4 Session_Setup RLL 4 NA Session_Setup+RLL+4 5 Session_Setup RLL 5

Hi , > df Session_Setup DCT FwdDataVols_bin counts Comp 1 User_Initiated NoRLL 1 5058 User_Initiated+NoRLL+1 2 User_Initiated NoRLL 2 584 User_Initiated+NoRLL+2 3 User_Initiated NoRLL 3 191 User_Initiated+NoRLL+3 4 User_Initiated NoRLL 4 128 User_Initiated+NoRLL+4 5 User_Initiated

Hello guys, I want to make echo tail parameter in my app changeable during run-time. So my question is:f Should I use speex_echo_state_reset function for this? Just call speex_echo_state_init function with new values after that? Or perform a full de-initialization and initialize echo cancellation with new tail value? I'm also using preprocessor - does the same apply to it?

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

https://bugzilla.samba.org/show_bug.cgi?id=13433 Bug ID: 13433 Summary: out_of_memory in receive_sums on large files Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter:

Hi, I recently came across a situation where "rsync --inplace" performs very poorly. If both the source and destination files contain long sequences of identical blocks, but not necessarily in the same location, the sender can spend an inordinate amount of CPU time finding matching blocks. In my case, I came across this problem while backing up multi-hundred-gigabyte MySQL database

Here http://lists.xiph.org/pipermail/theora/2004-September/000619.html Andrey describe encoder structure, this like: "I see the following structure of the compressor implemented in the FPGA (Xilinx Spartan 3 1000K gates): 1. Data from the external frame buffer (FB) memory goes to the Bayer-to-YCbCr (4:2:0) converter in overlapping 20x20 tiles that produce 6 8x8 blocks (one macroblock) on the