On Sat, Oct 02, 2004 at 06:52:40PM +0200, Richard Atterer wrote:
OK, I know now what causes the problem. I haven't found the error in JTE
(or jigdo-file?) yet.
Downloaders, as a short-term workaround add --no-check-files to jigdoOpts
in your ~/.jigdo-lite.
As of version 1.12, JTE not only outputs md5sums for each file, but also an
Rsync64Sum for the first 1k of each file. I asked Steve to implement this
- in the future, it'll allow the jigdo GUI to abort downloads early if the
checksum of the first 1k doesn't match during the download.
JTE 1.11 outputs a zero blockLen field to the .template, which switches
off comparison of Rsync64Sums by jigdo-file make-image (used by
jigdo-lite).
JTE 1.12 sets blockLen to 1024, but outputs a wrong Rsync64Sum. With our
example file, adduser_3.59_all.deb:
$ jigdo-file mt -fi adduser_3.59_all.deb -j grr.jigdo -t grr.template
adduser_3.59_all.deb
Match of `adduser_3.59_all.deb' at offset 0
Finished - image size is 93882 bytes.
$ jigdo-file ls -t grr.template
need-file 093882 K3IwZGUJlF7q6sCv7t8PfA kRjI35yjRzk
image-info 93882 K3IwZGUJlF7q6sCv7t8PfA 1024
$ jigdo-file ls -t grr.template --hex
need-file 093882 2b7230646509945eeaeac0afeedf0f7c
9118c8df9ca34739
image-info 93882 2b7230646509945eeaeac0afeedf0f7c 1024
This means that the Rsync64Sum expected by jigdo-file is kRjI35yjRzk, or
9118c8df9ca34739 in hexadecimal. For the algorithm, this means that
lo=0xdfc81891, hi=0x3947a39c.
I've found the cause of this bug:
==
--- jte.c~ 2004-09-05 17:35:53.0 +0100
+++ jte.c 2004-10-06 01:07:48.0 +0100
@@ -944,6 +944,7 @@
FILE *infile = NULL;
int use = 0;
unsigned long long rsync64_sum = 0;
+int first_block = 1;
memset(buf, 0, sizeof(buf));
@@ -964,8 +965,6 @@
while (remain 0)
{
-int first_block = 1;
-
use = remain;
if (remain sizeof(buf))
use = sizeof(buf);
==
fixes it. I was resetting first_block for every block :-(
Manty, can you please apply this to your copy of JTE before the next
DVD build please?
I'm now seeing another minor issue. jigdo-file ls shows
adduser_3.59_all.deb to have rsyncsum kRjI35yjRzk whereas my own debug
tools show it to be kRjI35yjRz5 - note the last character is
changed. The algorithm I'm using for printing the base64-encoded
numbers is the same as for the md5sum results, so I'm bothered by this
being wrong. I also can't see any mistake in the code.
Richard, PLEASE for future versions of jigdo drop this silly
bastardised base64 encoding that you're using. It makes life _very_
difficult when debugging things if the checksum output format is not
simple. Base 16 good, base 64 bad.
/rant.
--
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/
signature.asc
Description: Digital signature
