> On 26-04-2012 15:05, Thomas J. Hruska wrote:
>> On 4/26/2012 5:10 AM, OpenSSL wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>> OpenSSL version 1.0.1b released
>> Heads up warning: This archive under 7-Zip 9.20 (latest
>> stable) displays a "There are no trailing zero-filled records"
>> error dialog but then proceeds to work just fine. The last
>> time this happened there was discussion on the list but no
>> resolution. Ignoring the error seemed to work fine.
> This is not limited to 7-Zip, see also the post by Mr. Bergeron
> of IBM.
> I have looked closer at the tar.gz file (my download matches the
> checksums and digital signature from Dr. Henson), and the file
> is not valid according to the tar file format specifications that
> I have looked at.
> According to the basic tar specification, each file is prefixed by
> a 512 byte header with filename, size etc. and zero padded to a
> multiple of 512 bytes, and the last file is followed by at least
> 2x512 bytes of all-zero bytes to indicate end of file. Additional
> details vary among tar format versions, but these three aspects
> are amongst the common features.
> But the tar file inside the gzip file "openssl-1.0.1b.tar.gz"
> lacks those last 1024 bytes of zeroes. I think this must be a bug
> in whatever tool Dr. Henson used to create the file. 7-Zip 9.20,
> GNU tar 1.25 and BSD tar 2.8.3 all produce the correct format, but
> of those 3 only 7-Zip loudly complains about the missing
> end-of-file blocks. Mr. Bergeron seems to be using a 4th
> implementation (maybe a derivative of the original UNIX tar, maybe
> a version for an IBM OS) which also complains.
The perl Archive::Tar::Streamed module produces such invalid files if
the user forgets to call the writeeof method after adding the last file.
Mr. Bergeron's reported error message is the one produced by AIX tar
for truncated or unterminated tar files.