Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.5.0

Bug #17578 Fail to read some POSIX tar files
Submitted: 2010-07-11 23:27 UTC
From: miketee99 Assigned: mrook
Status: No Feedback Package: Archive_Tar (version 1.3.7)
PHP Version: 5.3.1 OS: tested on Linux and MaxOSX
Roadmaps: (Not assigned)    

Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem : 23 - 1 = ?

 [2010-07-11 23:27 UTC] miketee99 (Michel Terese)
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 (, 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)


 [2010-07-11 23:54 UTC] miketee99 (Michel Terese)
 [2010-07-12 00:01 UTC] miketee99 (Michel Terese)
-Operating System: tested on Linux et MaxOSX +Operating System: tested on Linux and MaxOSX
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
 [2010-09-03 20:01 UTC] kevinoid (Kevin Locke)
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).
 [2010-10-06 00:04 UTC] mrook (Michiel Rook)
-Status: Open +Status: Assigned -Assigned To: +Assigned To: mrook -Roadmap Versions: +Roadmap Versions: 1.3.8
Thanks for the patch!
 [2016-04-28 13:09 UTC] mrook (Michiel Rook)
-Roadmap Versions: +Roadmap Versions: 1.4.3
 [2017-02-08 14:34 UTC] mrook (Michiel Rook)
Michel, looks like I can't access your patch (anymore). Any chance you could submit this as a pull request to
 [2018-09-19 17:55 UTC] mrook (Michiel Rook)
-Status: Assigned +Status: No Feedback
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.