Thanks for this. Could you give me a bit more info:
Are you using checksumming?
Can you send the debug output of one of the 'stuck' retrievals
On Mon, Oct 22, 2007 at 01:03:49PM -0700, Tony Godshall wrote:
> When upstream server is caught mid-sync and apt-cacher downloads only
> a partial file,
> apt-get on client identifies it as a MD5Sum mismatch error.
>
> Without apt-cacher, this is easily handled- one simply runs "apt-get
> update && apt-get install $pkgs" again.
>
> With apt-cacher, the the partial file continues to be returned,
> resulting in a "stuck" condition in the
> clients.
>
> The code at issue appears to be...
>
> if (-f $complete_file) {
> # not much to do if complete
> # Possibly checksum cached file before delivery
> $cache_status = "HIT";
> debug_message("$cache_status");
> }
I have wondered if this piece of code is adequate. 1.5.5 checks the size
of the returned file against the cached header. See line 981. But this
will only pickup on disk corruption. Checksumming should have picked
this up, if you were using it.
In addition, to force refresh of a cached file, apt-cacher now honours
Pragma: No-cache. So doing
apt-get -o Acquire::http::No-Cache=true install $pkg
should have forced a fresh file to be downloaded.
I would be grateful if you could try this and tell me if it doesn't work
> Apparently apt-cacher assumes that a file downloaded with good status
> is complete, which makes it unusable for common situations, such as...
One solution seems to be to send a head request upstream and verify that
the cached file is the size expected. There seems likely to be a
significant overhead for that. Maybe we should use checksumming all the
time?
Thanks,
Mark
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
