In article <20030314142120.D722@snowdrop.l8s.co.uk>,
David Laight <david@l8s.co.uk> wrote:
>
>I've just looked at that broken archive - it is definitely badly stuffed.
>
>More particularly the archive should end at the end of one of the 10k
>data blocks.  However whatever produced the archive flushed its
>output buffer again.  This means that the last 10k of the file
>is identical to the last-but-one 10k.
>
>This specific case of an invalid archive could be detected, and the
>'valid header search' skipped [1].
>
>Has enyone looked at any other of these 'broken' archives, to know
>whether they always have 10k of junk padding?
>
>	David
>
>[1] is it right to unconditionlly perform this search, or should it depend
>on a command line flag?

Well, this is how historically tar behaved. Since old tapes used to be flakey
it was a good thing to try to recover by default. Old tape drives used to
be slow beasts, so it was a pain to spin a tape, then discover it had a flaw,
re-wind it and restart tar with the `recovery' option.

I think it is ok to keep it on for tar. I was contemplating turn it off
by default for pax, but I saw no real merit in doing so since all other
implementations that I know of try to recover by default and it would
make our pax look stupid. People actually wanted to go the other way
(to silently unpack corrupted archives and exit with 0), but this is
encouragement for more broken tar implementations.

christos