Storage compression patch for Rsync (unfinished)

[Dave Dykstra]

On Sun, Jan 26, 2003 at 02:46:43PM -0800, Craig Barratt wrote:
> > Is there any reason why caching programs would need to set the
> > value, rather than it just being a fixed value?
> > I think it is hard to describe what this is for and what it should be
> > set to.  Maybe a --fixed-checksum-seed option would make some sense,
> > or for a caching mechanism to be built in to rsync if it is shown to
> > be very valuable.
> 
> A fixed value would be perfectly ok; the same magic value that batch
> mode uses (32761) would make sense.
> 
> > I know people have proposed some caching mechanisms in the past and
> > they've been rejected for one reason or another.
> 
> One difficulty is that additional files, or new file formats, are needed
> for storing the checksums, and that moves rsync further away from its
> core purpose.
> 
> > I don't think I'll include the option in 2.5.6.
> 
> If I submitted a new patch with --fixed-checksum-seed, would you be
> willing to at least add it to the patches directory for 2.5.6?
> 
> I will be adding block and file checksum caching to BackupPC, and
> that needs --fixed-checksum-seed.  This will save me from providing
> a customized rsync (or rsync patches) as part of BackupPC; I would
> much rather tell people to get a vanilla 2.5.6 rsync release and
> apply the specific patch that comes with the release.


Sorry, but I don't think it would be good to do even that until we've all
had a chance to look at what's involved in the caching and whether or not
it would make better sense to have it be a modification to rsync rather
than mostly external.  I'm concerned that people might misuse the option
without understanding the consequences.  You could always keep the patch
on the BackupPC web site in the meantime.

- Dave