Milis linux-admin dan linux-setup sekarang telah digabungkan ke milis baru
dengan alamat . Untuk subscribe kirim email kosong ke
<[EMAIL PROTECTED]>.
Info milis selengkapnya di http://linux.or.id/milis.php
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Befor
On Sun, 2006-02-26 at 18:52 -0800, Wayne Davison wrote:
> This would be such an improvement for really large files
If the new hash table can handle really large numbers of blocks really
well, it might actually be practical for rsync to load all files in the
transfer into the hash table at the begi
On Sun, Feb 26, 2006 at 06:55:18PM +0200, Shachar Shemesh wrote:
> - Attacker puts just enough checksums in the count to make the 20%
> expansion overflow the 32bit variable.
Quite so. I also remembered the 20% expansion after I sent my email,
which (as you mentioned) does mean that we need to bu
Wayne Davison wrote:
>On Sun, Feb 26, 2006 at 10:34:25AM +0200, Shachar Shemesh wrote:
>
>
>>A line of credit would have been nice :-)
>>
>>
>
>Sure 'nuff.
>
>
Thanks.
>>2. In "sum_buf", sum1 is defined to be unsigned. It seems dangerous to
>>me to hash it into a signed index, even if it
On Sun, Feb 26, 2006 at 10:34:25AM +0200, Shachar Shemesh wrote:
> A line of credit would have been nice :-)
Sure 'nuff.
> I think we can save the memory when handling smaller files.
Yeah, I've been leaning the same way, so I like your change here. I
also like your reason for realloc() being th
Wayne Davison wrote:
>http://rsync.samba.org/ftp/unpacked/rsync/patches/dynamic_hash.diff
>
>
A line of credit would have been nice :-)
>One thing this patch does is to (1) leave the array allocated to its
>largest size, (2) use realloc() if we need to make it bigger, (3) make
>the minimum
