Re: Rsync and incremental updates on top of Original CDs
On Sat, Feb 24, 2001 at 01:18:26AM +0100, J.A. Bezemer wrote:
>
> On Fri, 23 Feb 2001, Richard Atterer wrote:
["jido-file copy-matching" command]
> > True, something like that would be useful. I think you could actually
> > get away with appending to potato.iso the information regarding which
> > files have already been copied into the image, and remove that
> > "trailer" when you're finally done. (It might be wise to use a name
> > "potato.iso.tmp" and only rename it to "potato.iso" when finished.)
>
> Nice idea, but AFAIK shortening a file is impossible (at least C
> doesn't seem to have a function for it). And besides, it would be
> very helpful if the "already-done" file was just plain ascii text
> (md5sum with filename as comment?) that could be changable easily,
> for example to force a file to be downloaded again (for whatever
> reason).
True, shortening of files was (erroneously?) omitted from ANSI C - but
it *is* present in POSIX. Linux has truncate(2) and ftruncate(2), the
latter is POSIX.
I wonder - will it be necessary to, say, download a file again?
jido-file will only write it to the image if its MD5 sum matches the
one in its list - that's a pretty strong check!
> The .tmp name for an unfinished image surely would make things a bit
> clearer to unexperienced users. I can imagine some "jido-finalcheck"
> tool that checks the md5sum (gotten from...where?
> --md5sumfile=MD5SUMS ? image=okay if matches any listed md5sum?) and
> if okay renames the .tmp to .iso.
Hm, shouldn't jido-file be doing this itself? I.e., print a message
"Not finished yet" and return 1, until the last missing file has been
supplied, then print "Finished", rename the file and return 0.
(But a separate command "jido-file verify" to verify the MD5 sum given
the image and the .template file would be useful - added that to my
[already long :-/] TODO list.)
> > > Followed by either
> > >
> > [ a) jido-file print-missing, then fetch files that are output and
> > jido-file copy-matching]
> > [ b) jido-net get-and-copy-missing
> > which would do the getting and copying at once.]
> >
> > I prefer a), because I want to draw a line between the jido-file tool,
> > whose main purpose it is to /generate/ the .template files (but which
> > is also capable of reassembling images as an add-on feature), and
> > jido, the "client program" with GUI, automatic mirror selection etc.,
> > which can only reassemble images from template+files+downloads, and
> > nothing else.
>
> Very well -- but don't be surprised if some guy who likes b) better
> suddenly mails you a "jido-net" implementation ;-)
No problem - in fact, a simple version can be done as a shell script
which uses wget or lynx. :) (And as I said, I *am* going to write a
real download program, I just want it to be a little more flexible.)
> Actually, now that you're an Official Developer, you should have
> access to a lot of Debian machines; I suppose a few have a local
> mirror and enough disk space to test things. And if not, we can
> probably arrange an account on cdimage.d.o (full local mirror, all
> official CDs and 7GB free in /home ;-).
<drool ;->
> (Not that I don't want to help; it's just that it might be easier to
> do/test things yourself. Unless you're using some terribly expensive
> slow modem connection of course...)
Well, not /terribly/ expensive, but I'm charged per minute for this
56kbps modem line... I have broadband net access at uni, but I develop
jido-file at home, plus it's the semester break now.
WRT this whole scheme, there's one further thing we need to think
about: Unlike the current pseudo-image-kit, it is assumed that all the
"puzzle pieces" that the CD image is assembled from are in fact
available. Is this guaranteed with the current way the Debian archive
is handled? For example, do security updates immediately replace
packages in the current stable release? They mustn't for this to work!
I know, you can always use rsync for any remaining missing bits, but
ideally, all this ought to work without rsync.
Cheers,
Richard
--
__ _
|_) /| Richard Atterer | CS student at the Technische | GPG key:
| \/¯| http://atterer.net | Universität München, Germany | 888354F7
¯ ´` ¯
Reply to: