[OSM-talk] Planet-latest.osm.bz2 corrupt?

[Jon Burgess]

On Wed, 2007-12-05 at 22:30 +0000, Jon Burgess wrote:
> On Wed, 2007-12-05 at 23:04 +0100, Lambertus wrote:
> > I tried downloading the latest planet-latest.osm.bz2 this evening from 
> > different sources. Everytime I get the following warning, is this just me?
> > 
> > --21:04:22--  http://planet.openstreetmap.org/planet-latest.osm.bz2
> >            => `planet-latest.osm.bz2'
> > Resolving planet.openstreetmap.org... 128.40.58.205
> > Connecting to planet.openstreetmap.org|128.40.58.205|:80... connected.
> > HTTP request sent, awaiting response... 200 OK
> > Length: 2,232,896,486 (2.1G) [application/x-bzip]
> > 
> > 100%[==================================>] 2,232,896,486  363.04K/s    ETA 
> > 00:00
> > 
> > 22:46:48 (354.80 KB/s) - `planet-latest.osm.bz2' saved 
> > [2232896486/2232896486]
> > 
> > 
> > bzip2: Data integrity error when decompressing.
> >         Input file = planet-latest.osm.bz2, output file = planet-latest.osm
> > 
> > It is possible that the compressed file(s) have become corrupted.
> > You can use the -tvv option to test integrity of such files.
> 
> The size matches the file on the server. I'm running a "bzip2 -t
> planet-071205.osm.bz2" on the server to verify whether the file is OK or
> not. It will take some time to complete. Could you run 'md5sum
> planet-latest.osm.bz2' on your file and send the result?
> 

The file looks OK according to bzip2 -t

For comparison:-

$ md5sum planet-071205.osm.bz2
61c0e87b90cb53ae7c404f9633fe61fc  planet-071205.osm.bz2

I saw similar transient bzip2 problems on a previous machine which went
away once the PSU was replaced. bzip2 stresses the CPU and memory far
more than many other applications and can fail at the slightest sign of
hardware instability.

	Jon