();
+
if (verbose > 3)
output_flist(flist);
diff -rupNP rsync-2.6.2/fnameconv.c rsync-2.6.2-fnameconv.clean/fnameconv.c
--- rsync-2.6.2/fnameconv.c 1970-01-01 02:00:00.0 +0200
+++ rsync-2.6.2-fnameconv.clean/fnameconv.c 2004-05-29 21:17:09.0 +0300
Ahoy,
On 2004/04/08 14:16, Donovan Baarda wrote:
>>Nice indeed, but the cost is enormous: you'll have to read the file
>>twice. When syncing a mostly-unchanged file that's larger than the disk
>>cache, that means doubling the runtime (and disk load) on the receiver's
>>side. Also, it means 'rdiff
On 2004/04/08 08:50, Donovan Baarda wrote:
>>In some cases you might prefer to actually store an signed signature
>>using something like GPG.
I think librsync should act as a black box that guarantees file
integrity (which, apparently, requires a whole file checksum). If
someone wants to add authe
Hi,
On 2004/04/05 07:21, Donovan Baarda wrote:
[snip]
> there are four ways crafted blocks can be use;
>
> 1) two crafted blocks in the "original" file
>
> 2) two crafted blocks in the "target" file
>
> 3) a crafted pair of "target" and "original" files with matching
> block(s)
>
> 4) a block
Hi,
It would have been a simple script with the extension I proposed
("create batch without patching",
http://www.mail-archive.com/[EMAIL PROTECTED]/msg09757.html).
Alternatively, you can use librsync's rdiff. That lets you can save the
patch information to a file and then transmit it only if it'
Ahoy,
On 2004/03/18 04:46, Donovan Baarda wrote:
> Why would rollsum.c be slightly _slower_ for CHAR_OFFSET=0?
Just measurement noise (background process kicking in and spoiling the
memory caches, or such). It sometimes errs slightly the other direction,
so I believe the two cases are identical
Hi,
On 2004/03/17 00:07, Donovan Baarda wrote:
>>Quoth RFC 1950:
>>"That 65521 is prime is important to avoid a possible large class of
>>two-byte errors that leave the check unchanged."
>>Not much of a difference in adversarial setting, though.
>
> And not much of a difference I think for rsync
Donovan Baarda wrote:
> On Tue, 2004-03-16 at 10:44, Eran Tromer wrote:
> with an 8-byte hash that means you tested approximately 2^64/2 crafted
> fletcher busting blocks to find a collision, yeah?
[snip]
> I thought that without using some sort of known vulnerability the
> f
Hi,
On 2004/03/15 03:49, Donovan Baarda wrote:
>>Note that, above, block hash collisions are very easy to find if you
>>know checksum_seed. The rolling Fletcher checksum1 is trivially
>>defeated. To defeat the k-bit truncated MD4 checksum2, just keep
>>generate random blocks having the same checks
Hi,
Currently, rsync --write-batch creates the batch fileset and also
updates the destination. I suggest adding the ability to disable the latter.
Motivation: I wish to sync two large but similar directories residing in
different machines. There is a slow (dial-up) network connection between
the
Hi,
The following lines in compat.c are rather imprudent:
if (read_batch || write_batch)
checksum_seed = 32761;
else
checksum_seed = time(NULL);
write_int(f_out,checksum_seed);
Setting checksum_seed to a constant in batch mode means block collisions
are reproducible
Hi,
I agree about some options not making sense with --read-devices though
such conflicts abound already. Syncing the content of a (hopefully
unmounted) block device definitely makes sense. FIFO files also make
sense -- in fact in Linux, the kernel presents pipes as a FIFO file in
some contex
Hi,
Thanks for your explanation. Before answering, I'll note that (as
mentioned in a followup) my patch has some unintended debugging cruft
and I'll gladly provide a clean patch if anyone's interested.
Well, here's my personal motivation. I have a remotely located server
with a 6GB disk, and
Eeek. I've just noticed that I've mailed the wrong diff -- this one has
a lot of rprintf() debugging cruft, and also a small bug.
If you'd like a clean version, just ask.
Eran
Eran Tromer wrote:
> Greetings,
>
> I'd like to propose a new option to rsync, whic
14 matches
Mail list logo
