similar to: MD4 bug in rsync for lengths = 64 * n

On Thu, 2004-04-08 at 12:36, Martin Pool wrote: > On 5 Apr 2004, Donovan Baarda <abo@minkirri.apana.org.au> wrote: > > > librsync needs a whole file checksum. Without it, it silently fails for > > case 1), 3), and 4). > > Yes, a whole-file checksum should be used with it. Presumably > something stronger than md4 like SHA-1. md4 is probably good enough for most

Hi, while implementing the rsync protocol in one of our projects I found that the current CVS version still has a MD4 bug. I'm using the FreeBSD libmd implementation and I still had checksum mismatches with protocol version 27 for files whose size was a multiple of 64 - 4 ( - 4 due to checksum_seed). A patch for todays CVS version is attached. Someone should also review the clean_fname()

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 and predictable. Thus, some files will be permanently "unlucky" in batch mode and will

On Tue, 2006-02-21 at 14:58 -0800, rsync2eran@tromer.org wrote: > A year ago we discussed the strength of the MD4 hash used by rsync and > librsync, and one of the points mentioned was that only collision > attacks are known on MD4. Could you please forward this into the bug tracker so it's not lost? -- Martin -------------- next part -------------- A non-text attachment was

On 24 Apr 2002, "Shirish H. Phatak" <shirish@tacitnetworks.com> wrote: > Since there appears to be a dedicated group of users and lots of > activity, maybe we can convince Martin to roll in these patches and make > a new release? I have been really lax in supporting librsync for the last few months, because of a new job and taking over maintenance of rsync

On Tue, Jan 28, 2003 at 11:22:14PM -0800, Craig Barratt wrote: > And I have several things I would like to work on and submit: > > - Fix the MD4 block and file checksums to comply with the rfc > (currently MD4 is wrong for blocks of size 64*n, or files > longer than 512MB). > > - Adaptive first pass checksum lengths: use 3 or more bytes of the MD4 > block

G'day, I've been working on a Python interface to librsync and have noticed that it uses md4sum code borrowed from Andrew Tridgell and Martin Pool that comes via rsync and was originally written for samba. Is there anything special about this code compared to the RSA md4sum code that can be found with libmd <"http://www.penguin.cz/~mhi/libmd/">? Python uses the RSA

For anyone who'd like to check out the latest release of my "rzync" [sic] test release, I've just released a new version. For those that might not have time to look at the code but could provide some feedback based on a rough description, I've created the following simple web page: http://www.clari.net/~wayne/new-protocol.html Here's the tar file of the new

The attached patch provides an additional check for the checksumming mode to ensure that a file that is actually written out to disk can be read back and has the same MD4 sum as the file on at the originating location. Regards, Nick. -------------- next part -------------- *** rsync-2.6.6pre1/receiver.c 2005-04-14 02:42:13.000000000 +0100 --- rsync-new/receiver.c 2005-07-26

I'm not sure if this is the appropriate forum for questions regarding librsync, but couldn't find any others. I'm trying to get librsync working properly on Solaris 2.7 and 2.8 Sparc servers. The problem is that while librsync appears to compile cleanly, "make check" fails the sources.test. Does anyone have any insight as to why this might be? Might I need a specific

Hi All, Any inputs on this issue? -- Shedi On Wed, Feb 21, 2024 at 5:12?PM Shreenidhi Shedi < shreenidhi.shedi at broadcom.com> wrote: > Hi All, > > Copying the content from the GH issue as is. > Need your inputs on the same. > FWIW, the coredump files generated in linux have xattr values which are > > 32 bytes. > > https://github.com/WayneD/rsync/issues/569

Skipped content of type multipart/alternative-------------- next part -------------- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.9/39 - Release Date: 2005-07-04

Hello everybody, About librsync, does anyone know how to patch the delta without creating a new file ? I used the librsync and it always generates a new file, which is embarrassing if the file is over 1Gb. I tried to store the new file in RAM, but it saturates the machine. Is there a possibility to write in the current file to be synchronized, although this file is currently being

I'm interested in these very questions (librsync-rsync relationship, remaining limitations of rsync, active prospects for ground-up rewrites), Google searches for rsync info have proved a little too vague due to the programs ubiquity. Much has certainly changed since this was written, could some people with knowledge in these areas could update martin's response for the state of rsync,

Hi all, I'm trying a java implementation of rsync for "fun and profits" ;-) helped by librsync 0.9.7 and jarsync (a died java implementation) So i started to implement rdiff command and for now i have a working signature command. With first test, i had the same signature file of testsuite/mksum.input/COPYING.sig but when i try with another dummy file, for each checksum pair :

On the subject of needed patches, I just recently completed a patch for librsync that fixed the mdfour code to have uint_64 or 2 uint_32's for size. Without this, the checksums on files >512Megs are incorrect. The code should drop into rsync without a hitch. The same goes for mdfour in samba, becuase that is where librsync got the code from anyway. Robert Weber University of

Hi, I am working on a replication tool for lustre filesystems. We have introduced a mechanism for getting the changes that have been made to a lustre filesystem - similar to inotify. We call this mechanism, changelogs. For performing replication, we open the source file using its 'file identifier' or FID (think of it an inode that is unique cluster wide) instead of its path. The file is

Wayne, Please consider the attached patch. This applies to the current CVS, and is independant of patches/local-batch.diff. As a matter of fact, I'm sure it would conflict heavily with local-batch.diff. This version of batch mode has a couple distinguishing features: Write-batch records (almost) the entire sender side of the conversation into one file. ("Almost" because it has

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 librsync 0.9.5 is released from rproxy.samba.org. This release contains small but important bug fixes. Changes in 0.9.5: * Bugfix patch from Shirish Hemant Phatak MD5 checksum: df1c35520e4b0bf9d6d7ac813ba86a14 *librsync-0.9.5.tar.gz - -- Martin Pool -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see

All, Does anyone know anything about librsync, and where it is currently maintained = on the web? It apparently is/was a samba project, but I'm not sure how it relates. The authors are listed as: Martin Pool <mbp@samba.org> Andrew Tridgell <tridge@samba.org> but I suspect someone else did the 0.9.5.1 update, because only 0.9.5 is = available on the rproxy site