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 0 93882 K3IwZGUJlF7q6sCv7t8PfA kRjI35yjRzk
>image-info 93882 K3IwZGUJlF7q6sCv7t8PfA 1024
>$ jigdo-file ls -t grr.template --hex
>need-file 0 93882 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.000000000 +0100
+++ jte.c 2004-10-06 01:07:48.000000000 +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. steve@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/
Attachment:
signature.asc
Description: Digital signature