[Mon Apr 24 23:17:44 EST 2000]
Dear Tux,
So, we now have an example of corruption detected by using file
checksums. I'm awfully glad we put them back in! So, now we just
have to work out what's going wrong!
I trapped into gdb, so we can poke around a little bit. Also, we have
both the old and new files present, which is pretty cool. The files
generated a match just at the end, which might be a little
suspicious. We're using the version wired to 1024-byte blocks, and
it's walking through the rproxy cvsweb tree in sourceforge. So
probably the header was less than 1024 bytes, but we fould a common
trailer.
(hsync ) Writing LITERAL(len=3733)
(hsync ) Writing COPY(off=7168, len=214)
(hsync ) flush 56 bytes of signature data
(hsync ) Writing SIGNATURE(len=56)
(hsync ) filesum is 1ce4f46035b8ad1921039e7ffbb31a77
(hsync ) Writing CHECKSUM(len=16)
(hsync ) Writing EOF
I'm finding this a bit strange because the original file has more than
214 bytes after position 7168. In fact's it's 8406 bytes long. Huh.
The 214 bytes of the old file starting at position 7168 are
[[[hange='document.diff_select.r2.selectedIndex=0'>
Type of Diff should be a