Re: Rsync and incremental updates on top of Original CDs

["J.A. Bezemer" <costar@panic.et.tudelft.nl>]

On Mon, 5 Mar 2001, Richard Atterer wrote:

> Uh, sorry, I forgot about following up to this.
> 
> On Tue, Feb 27, 2001 at 12:58:20AM +0100, J.A. Bezemer wrote:
> > (Since positions and md5sums of individual files in the image are known, I
> > could imagine some "jido-file check-all-files-in-this-image" tool ;-) 
> 
> I was thinking of having jido-file do the MD5 check automatically for
> each file as it is being written to the image. If the MD5 sum doesn't
> match, the file will never be marked as copied-to-image.

You mean sync()ing after each write and checking by re-reading directly from
the image? That would get _very_ slow. And it's quite a bit overdone too,
since there usually won't be any problem and checking the md5sum of the entire
finished image will be enough. So if you implement anything like this, put it
under a non-default switch.

> [snip]
> > Which reminds me: the doc/ directory on FTP is constantly changing. 
> > This isn't very much (3-4 MB), but it's replicated on many CDs. One
> > option would be to include it literally in every template that needs
> > it, but a separate .tgz would probably be wiser (just "download;
> > untar; jido-file copy-matching" before anything else).
> 
> The template data is compressed, so just including doc/ there would be
> OK. But it is up to you, really. One problem is that the jido
> /download/ tool proper would have to have untar functionality
> built-in.

Correct, it's nothing you have to worry about at this moment; it's just
something we should remember when creating templates for the official images.

BTW, having complete untar functionality isn't strictly necessary; you can
also invent your own simple "archive" format like

  <md5sum> <length> <contents> <md5sum> <length> <contents>
  16 bytes  4 bytes  N bytes      16       4         N      EOF

and copy-matching on the fly while examining this "archive". Well, just an
idea ;-)


Regards,
  Anne Bezemer