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

Bug #18033 _getRegExpableSearchString() in File.php causes issue with paths
Submitted: 2010-11-09 02:40 UTC
From: justdev Assigned: dufuz
Status: Closed Package: PEAR_PackageFileManager_Plugins
PHP Version: 5.3.3 OS: Windows 7
Roadmaps: (Not assigned)    
Subscription  


 [2010-11-09 02:40 UTC] justdev (Justin Carlson)
Description: ------------ I believe I found an issue with SVN (though I think it should also be breaking CVS targets and that has worked in the past). Here is what I've got in my head as the issue... In: File.php: function _getRegExpableSearchString($s) {} The directory slashes are replaced with DIRECTORY_SEPARATOR: $s = str_replace('/', DIRECTORY_SEPARATOR, $s); Yet, the $packagedirectory always uses forward slashes, because setOption in PackageFileManager2.php alters it here: $options['packagedirectory'] = str_replace(DIRECTORY_SEPARATOR, '/', realpath($options['packagedirectory'])); if ($options['packagedirectory']{strlen($options['packagedirectory']) - 1} != '/') { $options['packagedirectory'] .= '/'; } So it seems like the ignore or only include options will never match for Windows users. Svn.php sets the include option to: $this->_setupIgnore(array('*/.svn/entries'), 0); In File.php _checkIgnore(). this is translated to: /^.*\\\.SVN\\ENTRIES$/ Which will never match: C:/HTDOCS/PROJECTS/JRC92/CONTROLLERS/MAIN/TEMPLATES/XML/.SVN/ENTRIES Because the \ were removed and replaced with / Expected result: ---------------- .SVN/ENTRIES should match Actual result: -------------- .SVN/ENTRIES doesn't match and isn't processed.

Comments

 [2011-03-24 05:08 UTC] dufuz (Helgi Þormar Þorbjörnsson)
-Package: PEAR_PackageFileManager +Package: PEAR_PackageFileManager_Plugins
 [2011-03-28 07:48 UTC] dufuz (Helgi Þormar Þorbjörnsson)
-Status: Open +Status: Closed -Assigned To: +Assigned To: dufuz
This bug has been fixed in SVN. 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.