similar to: rsync 2.6.0 (final) released

Rsync release 2.5.6 is now available at http://ftp.samba.org/ftp/rsync/rsync-2.5.6.tar.gz ftp://ftp.samba.org/pub/rsync/rsync-2.5.6.tar.gz rsync://ftp.samba.org/ftp/rsync/rsync-2.5.6.tar.gz There is a '.sig' file at corresponding URLs with a gpg signature; the public key is available on the pgp keyservers. NEWS for rsync version 2.5.6, aka the dwd-between-jobs release Changes

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

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

Hi Donovan, Thank you for the insight. I will keep you posted on this. Best Regards Naveen A. >From: Donovan Baarda <abo@minkirri.apana.org.au> >To: Naveen Athresh <naveenathresh@hotmail.com> >CC: rsync@samba.org,librsync developers list ><librsync-devel@lists.sourceforge.net> >Subject: Re: rsync - windows how should I compile the code any clues >-Thanks

On Mon, Dec 15, 2003 at 10:51:08AM -0800, Wayne Davison wrote: > On Mon, Dec 15, 2003 at 10:03:28AM -0800, jw schultz wrote: > > > The one thing i really would have liked to have seen in a version bump > > would have been changing the default remote shell to ssh instead of > > rsh/remsh. > > I can see this being both a good thing (since I think it is a better >

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

The first rsync-2.5.6 pre-release version is now available at: http://rsync.samba.org/ftp/rsync/preview/rsync-2.5.6pre1.tar.gz ftp://rsync.samba.org/pub/rsync/preview/rsync-2.5.6pre1.tar.gz rsync://rsync.samba.org/ftp/rsync/preview/rsync-2.5.6pre1.tar.gz There's also a corresponding '.sig' file that contains a gpg signature of the file; the public key is available on the

On Mon, 10 Nov 2003, Wayne Davison <wayned@samba.org>?wrote: > >?... This fix is also in CVS (along with several others). As another poster pointed out recently, it's been a long time since 2.5.6 was released (Jan 28 2003). Many recent replies to questions posted to this list are variants of "It's already fixed in CVS". Are there any particular reasons for holding

The changes made to 2.6.0pre1 have been pretty minor so far, so I had been debating whether we needed a pre2 release or not. I finally decided to go ahead and release what little there is, just to give folks a final opportunity to double check the final release: http://samba.org/ftp/rsync/preview/rsync-2.6.0pre2.tar.gz http://samba.org/ftp/rsync/preview/rsync-2.6.0pre2.tar.gz.sig

Mark II of the patch set. The first patch (dynsumlen2.patch) increments the protocol version to support per-file dynamic block checksum sizes. It is a prerequisite for varsumlen2.patch. varsumlen2.patch implements per-file dynamic block and checksum sizes. The current block size calculation only applies to files between 7MB and 160MB setting the block size to 1/10,0000 of the file length for a

On Fri, Jan 17, 2003 at 05:42:41PM -0800, Wayne Davison wrote: > On Fri, Jan 17, 2003 at 04:21:59PM -0800, jw schultz wrote: > > It should not do /root2/i386/etc/init.d/rsyncd and so on as > > -R would have it. > > -R would only do that if you actually prefixed the paths with the source > dir, which is not what happens with --files-from. The source dir is > just used

Hello all, I saw on the Release notes that 2.6.0 is using protocol version 27 which is different than 2.5.7 and 2.5.6. I did a quick peak through the rest of the release notes and quickly browsed the archives on the list and I didn't see any notes on how well 2.6.0 works with older versions of rsync. At our site, we do have 2.5.7 and 2.5.6 installed. Are there any documented problems when

I've been working on an update to my --files-from patch that I think will soon be ready to be committed to CVS. See if you agree. For those that have been following the saga, here's a list of just the changes since the last patch (for those that haven't, see the next section): Changes Since the Last Release: =============================== - The --null option was renamed to

On Wed, 7 Jan 2004 17:33:36 -0800, Wayne Davison <wayned@samba.org> wrote: > On Wed, Jan 07, 2004 at 04:15:57PM -0800, jw schultz wrote: > >> Runtime variable sized structures should be avoided. Do you want >> to make rdev, link and sum conditional also? > > The difference between these other items you mentioned is that we aren't > talking about making them

Hi everyone. Has anyone experienced rsync 2.6.0 causing huge amounts of system load? Especially on Linux 2.4? We recently upgraded our "push" machine to rsync 2.6.0 and the next push that went out (rsyncing about 3GB of data to 15 servers sequentially over gigabit ethernet) caused the box to hit 110.59. We only know the load because snmpd was still working, but nothing else in userspace

2000) into dos, and with your boot disk, read the share listing of machine A from a linux box and mount it, and the rsync the whole drive if shared (say c:\ with c:\winnt and all the good stuff). Though, i still could NOT actually restore this 'mirror' image like i could a 'mirror' image of a linux root?? So, ultimately, there is no reason to even waste the hard-drive space

One thing that's bugged me is that some of the man page lines in the options summary are longer than 79 chars and wrap onto the next line. These are just one line summaries (detailed description appear later) so they can, and should, be terse. Here's an edited diff showing my proposed changes (and a 79 char ruler):

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

On Sun, Dec 14, 2003 at 11:32:07PM -0600, John Van Essen wrote: > would you care to take the bull by the horns and produce a release > candidate for 2.5.8 so that the rsync enthusiasts on the rsync mailing > list can give it a whirl prior to an official release (hopefully by > Christmas)? I was just about to say something about this on the list, so I'll do it in reply to your