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

Bug #11594 _readLongHeader leaves 0 bytes in filename
Submitted: 2007-07-12 17:42 UTC
From: jamessas Assigned: jamessas
Status: Closed Package: Archive_Tar (version 1.3.2)
PHP Version: 5.2.1 OS: All
Roadmaps: (Not assigned)    
Subscription  


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:
MUST BE VALID
Solve the problem : 31 - 23 = ?

 
 [2007-07-12 17:42 UTC] jamessas (James Sas)
Description: ------------ When there is a long filename condition that requires the use of _readLongHeader, the filename string buffer is not unpack()'d, leaving zero bytes at the end of the string. to recreate, add any file to an archive having a filename longer than 100 characters. subsequent reading of the archive produces the incorrdct filename. the solution, contained in the patch, is to properly unpack/trim the zero bytes off the end of the long filename, using trim() or unpack(). trim($v_filename); or unpack("a".(512*($n+1))."filename", $v_filename); in keeping with the style of the package code, the patch uses the unpack method.

Comments

 [2007-07-12 17:50 UTC] jamessas (James Sas)
forgive me, but upon reading my entry i incorrectly stated that i'd used the unpack() method in the patch. having done some further reading of the source, i noticed that trim() was used in _readHeader() and so the patch actually contains trim().
 [2007-08-18 21:46 UTC] cellog (Greg Beaver)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.