Incorrect read length, http and php

[John Arbash Meinel]

Aaron Bentley wrote:
> David Allouche wrote:
>>> This problem has probably not been reported before because I do not
>>> think there are many php-based projects using bzr. But it's still here
>>> lurking to bite unsuspecting dumb-server clients.
> 
> It's not just that the server has php enabled, it's that the server has
> a terrible rule for detecting php files.  My organization has php
> enabled on our server, and I've never had that kind of problem serving
> knits.
> 
>>>  * It would be good if checksums were stored in knit indexes and used to
>>> detect data corruption during transport.
> 
> I think we've discussed that before, and I'm in favour.  It would mean
> my parent_checking patch wouldn't require an additional round trip.
> 
> Aaron

We do want to try and keep the index files small, since they have to be
completely read for any operation. (dictionary compression requires that
you know the full contents)

Also, I think it is more useful to keep a small checksum (like
crc/adler) of the compressed .knit contents, rather than the sha hash of
the full text. Because to check the full text, you have to extract the
data, and expand it from parents, etc. Versus just checking that the
compressed data matches the right crc. If you want to check the sha
hash, you have to extract it anyway, which means you might as well get
the sha from the .knit. (though you can't rely on the crc/adler to be
stable after compression. I suppose you could have the crc of the
uncompressed delta).

Also, in the php case, the .kndx file is going to be served as php as
well, so it isn't like we will be reading the index, and then reading
bogus data for the .knit file.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060921/46d7d6b2/attachment.pgp