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

Bug #8187 paths get too much mangled
Submitted: 2006-07-11 19:41 UTC
From: patrick dot strasser at tugraz dot at Assigned: pfischer
Status: Closed Package: File_Archive (version 1.5.3)
PHP Version: Irrelevant OS:
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


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 : 16 + 6 = ?

 
 [2006-07-11 19:41 UTC] patrick dot strasser at tugraz dot at (Patrick Strasser)
Description: ------------ File_Archive::read() mangles path too much. It's not valid to remove "." from path at will. "." is most likely significant, and the OS can work out pathes quite well, so there is no need to mangle the path. Example: File_Archive::read("./".$filename."/"); One would expect to read the file with name $filename as directory (expecting it to be an archive). But when $filename is empty, the path is ".//", wich resolves to "./" on any posix system, which is the current directory. File_Archive resolves this to "/", which is the root directory, though. Quite unfine. The Problem is in File_Archive_Reader::getStandardURL($URL). Before "if (strncmp($std, "./", 2) == 0) {", /\/*/ should be replaced by "/", or better no mangling should happen at all. Test script: --------------- $farchive = File_Archive::read("./".$filename."/"); print_r ($farchive); Expected result: ---------------- file_archive_reader_directory Object ( [directory] => /path/to/test/script/ [maxRecurs] => -1 [directoryHandle] => [source] => [symbolic] => ) Actual result: -------------- file_archive_reader_directory Object ( [directory] => / [maxRecurs] => -1 [directoryHandle] => [source] => [symbolic] => )

Comments

 [2007-01-08 19:09 UTC] pfischer at php dot net (Pablo Fischer)
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. You are right, fixed in CVS. Thanks and sorry for the delay!