similar to: MD4 checksum_seed

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

What is the point to checksum_seed? When reading/writing batch, it is initialized to a constant value, otherwise it is initialized to time(NULL). It certainly has no useful cryptographic value :) I got the go-ahead from the client on my --link-by-hash proposal, and the seed is making the hash unstable. I can't figure out why the seed is there so I don't know whether to cirumvent it in

I am the author of BackupPC (http://backuppc.sourceforge.net) and I am working on adding rsync support to BackupPC. I am implementing the server-side in perl, and the client will run vanilla rsync. (BTW, is there the protocol documented? I've answered all my questions by looking at the source, but it would be great to check against any docs.) I started with librsync 0.9.3 and the

Any feedback on this patch and the possibility of getting it into CVS or the patches directory? Thanks, Craig ---------- Forwarded message ---------- To: jw schultz <jw@pegasys.ws> From: Craig Barratt <cbarratt@users.sourceforge.net> cc: rsync@lists.samba.org Date: Sat, 01 May 2004 17:06:10 -0700 Subject: Re: setting checksum_seed jw schultz writes: > > > There was some

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

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

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

I've released version 2.6.0 of rsync. Two important things to note in the new release: 1. The default remote shell is now "ssh" unless you tell the configure you want to use something else. 2. Some bug fixes in the include/exclude code, while making things work properly, have resulted in some user-visible changes for certain wildcard strings. Read the

Hello, Object of my mail : 1/ stick a problem of incompatibylity between 2 patches (fileflags.diff & detect-renamed.diff) 2/ proposition of a correction I wanted to run rsync on a mac (OS X 10.6.5) with the --detect-renamed option. I therefore tried to compile rsync with the 3 relevant patches : - fileflags.diff - crtimes.diff - detect-renamed.diff But the patch detect-renamed.diff is

Dear collegaues, please evaluate the patch attached, which allow to use both --detect-renamed and --fileflags extra features. This is meta-patch which sould be applied to detect-renamed. fileflags patch should be applied first, following by the modified detect-renamed patch. It is included in current FreeBSD port, but it seems it would be much more useful to be supported by samba

Hi folks, I have several build environments in which I must build rsync, and in some, but not all of them, the build fails when built with -Wall -Werror due to this warning: In file included from /usr/include/string.h:495, from /home/demartin/BuildClients/cobrasync-8.80-alsi11-lib32/cobrasync/rsync-3.2.7/rsync.h:339, from

> Just curious: what about the rsync+ patch? Thanks for the reminder. I've just committed Jos's rsync+ patch onto the "branch_mbp_rsyncplus_merge" branch. If it works OK and nobody screams I will move it across onto the main tree tomorrow or Wednesday. I see the patch doesn't add documentation about the new options to the man page, so we should fix that in the future.

From: Sebastian Andrzej Siewior <sebastian at breakpoint.cc> This is a huge all-in-one patch and deserves a little cleanup and splitting. However, I wanted to get it out here for some feedback. My primar motivation to use SHA1 for checksumming (by default) instead of MD5 is not the additional security bits but performance. On a decent x86 box the SHA1 performance is almost the same as

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

I'm in the midst of coding a patch set for consideration that will bump the protocol version and have a couple of observations. The current minimum backwards-compatible protocol is 15 but we have code that checks for protocol versions as old as 12. If someone else doesn't beat me to it i'm considering cleaning out the pre-15 compatibility code. A backwards compatibility patch could

Hi, Where can I get good pointers on the rolling checksum algorithm used in rsync? I need an 8-bit or 12-bit rolling checksum too. Any place where "rolling" checksum algorithms are discussed? Seun Osewa ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

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

Recently I have been building LLVM and Clang from the distribution using gcc 4.9.2. With the new 5.0.0 rc2 that is giving warning messages during the compilation. I have been trying out some other compilers. gcc 5.2 with -std=c++11 This works, although there are still some warnings. gcc 6.4 and gcc 7.1 fail with errors such as this in building libcxxabi as follows: Command: