search for: s2length

...tprint sums array which could compounded by the sum hash could be a limiting factor on the size file a given machine can reasonably handle. The second table shows the effect of --block-size=16384 and is indicative of what setting a MAX_BLOCK_SIZE would do. file length block_len block_count s2length xmit sums array_size 50 700 1 2 6 36 831K 920 926 2 5556 32K 1439K 1208 1221 2 7326 42K 2493K 1592 1604 2...

...9;ll work with later versions: the onus is on @@ -385,7 +385,8 @@ OFF_T flength; /**< total file length */ size_t count; /**< how many chunks */ size_t remainder; /**< flength % block_length */ - size_t n; /**< block_length */ + size_t blength; /**< block_length */ + size_t s2length; /**< csum_length */ struct sum_buf *sums; /**< points to info for each chunk */ }; --- generator.c Sat Mar 22 03:38:21 2003 +++ generator.c.dynsumlen Sat Mar 22 09:47:43 2003 @@ -109,13 +109,21 @@ /* - send a header that says "we have no checksums" down the f_out fd +...

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

OK, I packaged up the current CVS as our first preview release for 2.6.0. You can grab it here: http://samba.org/ftp/rsync/preview/rsync-2.6.0pre1.tar.gz The MD5 checksum is: 70e9dea967f083c231b7821ef35aef1b rsync-2.6.0pre1.tar.gz There is not currently a .sig file for the package, but I'm looking into that next. Please test this and let me know if we have any remaining issues

https://bugzilla.samba.org/show_bug.cgi?id=2187 ------- Additional Comments From qiucheng@csc.com.cn 2004-12-27 01:15 ------- Created an attachment (id=869) --> (https://bugzilla.samba.org/attachment.cgi?id=869&action=view) error log -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact

...J.W. Schultz's code) assumes that the hashes are random. This is a reasonable assumption for the truncated MD4 checksum2 when checksum_seed is random, but it's a pretty rotten assumption for the Fletcher checksum1. For the purpose of evaluating the probability of retransmission, rsync uses s2length bytes of good hash plus 4 bytes of wishful thinking, and Baarda's analysis doesn't really apply. Eran

...ecv(2) starting pid=395 recv_file_name(old.zip) received 1 names recv_file_list done get_local_name count=1 ../new.zip generator starting pid=395 count=1 delta transmission enabled recv_generator(../new.zip,0) generating and sending sums for 0 send_files(0, ../old.zip) count=624 rem=638 blength=700 s2length=2 flength=436738 recv_files(1) starting send_files mapped ../old.zip of size 498783 calling match_sums ../old.zip old.zip built hash table hash search b=700 len=498783 match at 700 last_match=0 j=1 len=700 n=700 match at 1400 last_match=1400 j=2 len=700 n=0 match at 2100 last_match=2100 j=3 len=700...

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

https://bugzilla.samba.org/show_bug.cgi?id=1529 wayned@samba.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From wayned@samba.org 2004-07-14 09:55

I've merged the security fixes that were released in version 2.5.7 into CVS. I also made similar changes to the malloc() calls that are new in the CVS version. This version has received very minimal testing, but it looks good so far. ..wayne..

...1 names 1 file to consider recv_file_list done get_local_name count=1 ./ recv_files(1) starting generator starting pid=25013 count=1 delta transmission enabled recv_generator(bigtestfile,0) send_file_list done send_files starting generating and sending sums for 0 count=56894 rem=56488 blength=56888 s2length=4 flength=3236585472 Killed by signal 2. The interesting thing is that the actual file size on both ends is 7531552768, but the size claimed by rsync is exactly 4gig less than that, which is also the remainder of the size that fits in a 32bit unsigned int, which looks like a 32bit rollover or var...

...le_name(history) received 1 names done recv_file_list done get_local_name count=1 /cvsroot/uclinux533/CVSROOT/history recv_files(1) starting generator starting pid=27391 count=1 delta-transmission enabled recv_generator(history,0) generating and sending sums for 0 count=33367 rem=2109 blength=33352 s2length=3 flength=1112824941 generate_files phase=1 and then nothing. If I strace the process, I get home/home/rgetz/testcvs/gcc1 # strace -p 27391 Process 27391 attached - interrupt to quit select(5, [4], [], NULL, {22, 983000}) = 0 (Timeout) select(5, [4], [], NULL, {60, 0}) = 0 (Timeout) sele...

...lient_run (f_in=5, f_out=4, pid=1713, argc=1, argv=0x12461c) at main.c:1003 #6 0x0040ffb7 in start_client (argc=1, argv=0x12461c) at main.c:1171 #7 0x004104d3 in main (argc=2, argv=0x124618) at main.c:1381 Here's the locals: c = 2147026704 l = -1 b = 262474876 len = -2073107852 blength = 700 s2length = 9174100 As we can see l is -1 which I believe is the issue. I can understand it not being able to deal with the given file given the 32bit file size restrictions but Im sure an infinite loop is not the best result so any advice would be appreciated. Regards Steve ===================...

...lient_run (f_in=5, f_out=4, pid=1713, argc=1, argv=0x12461c) at main.c:1003 #6 0x0040ffb7 in start_client (argc=1, argv=0x12461c) at main.c:1171 #7 0x004104d3 in main (argc=2, argv=0x124618) at main.c:1381 Here's the locals: c = 2147026704 l = -1 b = 262474876 len = -2073107852 blength = 700 s2length = 9174100 As we can see l is -1 which I believe is the issue. I can understand it not being able to deal with the given file given the 32bit file size restrictions but Im sure an infinite loop is not the best result so any advice would be appreciated. -- Configure bugmail: https://bugzilla.samb...

I'd like some opinions on a couple of long-standing rsync issues. My two oldest, uncommitted patches are: - A "no hang" patch that makes sure that the pipe from the receiver to the generator can't block with resend requests. - The "move files" patch that got changed into a --delete-sent-files option. For each item I have two questions -- do we need to

...Priority: P5 Component: core Assignee: wayned at samba.org Reporter: toasty at dragondata.com QA Contact: rsync-qa at samba.org I'm attempting to rsync a 4TB file. It fails with: generating and sending sums for 0 count=33554432 rem=0 blength=131072 s2length=6 flength=4398046511104 chunk[0] offset=0 len=131072 sum1=8d15ed6f chunk[1] offset=131072 len=131072 sum1=3d66e7f7 [omitted] chunk[6550] offset=858521600 len=131072 sum1=d70deab6 chunk[6551] offset=858652672 len=131072 sum1=657e34df send_files(0, /bay3/b.tc) count=33554432 n=131072 rem=0 ERROR: out...

...bytes, did move send_file_list done deleting in . recv_files(2) starting generator starting pid=1001 count=2 delta transmission enabled recv_generator(.,0) set modtime of . to (1075148267) Mon Jan 26 15:17:47 2004 ./ recv_generator(foo,1) generating and sending sums for 1 count=1 rem=4 blength=700 s2length=2 flength=4 generate_files phase=1 recv_files(foo) recv mapped foo of size 4 foo got file_sum renaming .foo.cJC1Ra to foo set modtime of foo to (1075148267) Mon Jan 26 15:17:47 2004 recv_files phase=1 generate_files phase=2 recv_generator(.,0) set modtime of . to (1075148267) Mon Jan 26 15:17:47 20...

...ev) +[Receiver] change_dir(/root) -generator starting pid=2490 +generator starting pid=2486 delta-transmission enabled -recv_generator(dm-7,0) +recv_generator(file,0) -gen mapped dm-7 of size 0 *** +gen mapped file of size 64400243 generating and sending sums for 0 +count=8026 rem=7643 blength=8024 s2length=3 flength=64400243 %%% recv_files(1) starting The line I marked with *** seems to indicate the size of dm-7 is 0. The line marked with %%% seems to indicate that in case of the destination being a file hashes are produced, but that lack of this line in the output when the destination is a devic...

...list done get_local_name count=2 /tmp/test_rsync/ recv_files(2) starting generator starting pid=12320 count=2 delta transmission enabled recv_generator(.,0) recv_generator(maxim_file.dat,1) generating and sending sums for 1 send_files(1, /tmp/test_rsync/maxim_file.dat) count=729 rem=128 blength=720 s2length=2 flength=524288 send_files mapped /tmp/test_rsync/maxim_file.dat of size 524288 calling match_sums /tmp/test_rsync/maxim_file.dat maxim_file.dat built hash table hash search b=720 len=524288 done hash search sending file_sum false_alarms=0 tag_hits=5722 matches=0 sender finished /tmp/test_rsync/ma...

...n main (argc=2, argv=0x18da230) at main.c:1630 --and again some time later -- root at st1:~# gdb /usr/bin/rsync 4942 --snip-- 0x000000000042648c in hash_search (f=1, s=0x192d220, buf=0x192d1e0, len=214748364800) at match.c:236 236 if (memcmp(sum2,s->sums[i].sum2,s->s2length) != 0) { (gdb) bt #0 0x000000000042648c in hash_search (f=1, s=0x192d220, buf=0x192d1e0, len=214748364800) at match.c:236 #1 0x0000000000426cf4 in match_sums (f=1, s=0x192d220, buf=0x192d1e0, len=214748364800) at match.c:398 #2 0x000000000041a175 in send_files (f_in=0, f_out=1) at sender.c:391 #...