From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-02-01 16:31:56
On Tue, 01 Feb 2005 19:31:53 +0100, Stefan Slapeta <stefan_at_[hidden]> wrote:
> This is a typical error that occurs after an incomplete tarball download
> (which happens quite frequently, and _when_ it happens, its
> reproducible, say, you can't download a complete tarball then for about
> an hour! I always thought this is a problem of our proxy.)
> At least, this says that the utils directory isn't on your hard disk.
> Just test the integrity of your tarball...
And so it is. I've run into this once before but I guess I forgot this answer.
I suspect that I grabbed the tarball while it was still being created.
If this is the case, can the tarball script be modified to create the
file using a temporary name and then removing the old file and
renaming the new one when tar finishes?
> BTW, it's strange that the testing script continues even if the tarball
> isn't complete. Isn't there an error reported from the extraction routine??
It appears then when the Python TarFile object is used in pipe mode,
it is unable to detect errors in the file it is processing. I took a
100k chunk of the boost-CVS-HEAD.tar.bz2 tarball and ran it through
the following code:
for file in sys.argv[1:]:
tarfile.open (file, "r|bz2").list()
The program proceeds to list the first 200+ entries in the truncated
tarfile, and then exit silently. If the mode string is changed to
"r:bz2", the initial 200+ entries are again listed, but the corruption
is detected and an exception is thrown.
I'd suggest that regression.py be changed to use the "r:" mode syntax
(assuming this doesn't try and decompress the entire file in-core)
-- Caleb Epstein caleb dot epstein at gmail dot com
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk