Description: ------------ Some POSIX tar files generated by non GNU tar programs (IBM AIX) cannot be read by Archive_Tar. The cause is the following: The end-of-archive entry not checked. Detailed explanation: As described in the tar format (http://www.gnu.org/software/automake/manual/tar/Standard.html), a tar archive must end with "an end-of-archive entry, which consists of two 512 blocks of zero bytes". In the current stable version 1.3.7, the Archive_Tar package don't check the end-of-archive entry assuming that the tar archive ends at the end of the tar file. Generally, there is no more blocks in the tar file beyond the end-of-archive entry (which would be useless). But, it happens, sometimes, for an unknown reason, that tar files generated on AIX 5.3.3, have some garbage blocks appended, after the end-of-archive entry. In that case, the Archive_Tar package attempt to read inconsistent data beyond the end of the archive which leads the read methods to fail. I fixed this, and I do some minor improvements in the block checksum calculation which can be significant with tar archives containing a huge quantity of files. Test script: --------------- <?php require_once( 'Archive/Tar.php' ); PEAR::setErrorHandling(PEAR_ERROR_PRINT); $tar= new Archive_Tar( 'some_tar_file.tar' ); if ( ($v_list= $tar->listContent() ) != 0 ) { for ( $i= 0; $i < sizeof( $v_list ); $i++ ) { echo $v_list[$i]['filename']."\n"; } } ?> Expected result: ---------------- ... The list of the files contained in the tar file ... Actual result: -------------- Invalid checksum for file "t;font-family:"Bookman Old Style";color:navy'><![if !supportEmptyParas]> <![endif]><o:p></o:p>" : 43686 calculated, 1 expected (of course, the name of the file reported depends on the content of the tar file)

Added patch end-of-entry_check.

All the modified and added code lines are delimited by comments like: // BEGIN !!== Modified/Added by Michel TERESE ==!! ... // END !!== Modified/Added by Michel TERESE ==!! The submitted patch can be applied by: patch -p1 Tar.php.patch

I was just bit by this bug as well. Note that the POSIX ustar format spec also refers to these 0 blocks as an "end of archive indicator" implying data after should be ignored. Note also that there are programs which only generate a single 0-block to indicate the end of archive and this case is supported by GNU tar (with a warning) and Python tarfile (no warning) and probably others (those are the only ones I checked).

Thanks for the patch!

Michel, looks like I can't access your patch (anymore). Any chance you could submit this as a pull request to https://github.com/pear/Archive_Tar?

No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you.