Richard Quadling wrote: > 2008/5/13 Antony Dovgal <[EMAIL PROTECTED]>: > >> On 13.05.2008 01:45, Gregory Beaver wrote: >> >>> Thanks to all who have contributed, particularly Marcus, Steph, Lars, >>> and the others who chimed in with ideas on the list. >>> >> phar_detect_phar_fname_ext() fails if is_complete = 1 and filename contains >> ".". >> >> For example: >> Breakpoint 1, phar_detect_phar_fname_ext (filename=0x124db80 >> "/local/qa/5_3.zts/ext/phar/tests/DataArchive.phar", check_length=1, >> > > > Am I being picky in saying that having a . in a folder containing a > file should be allowed? And if there is an extension on the filename, > then it will also have a . > This was always the intention, and is already fixed. In fact, opening URLs like phar://whatever/has.dot/my.phar/internal/file.php already worked, the only thing broken was instantiating a Phar object with a path containing "." > What happens for relative filenames?
They have worked since phar 2.0.0a1. The only requirement for phar to detect its file is that you either use a registered alias or that the filename contain a ".". Executable phar archives must also contain ".phar" as part of the filename extension. In short, the problem with Phar objects crept in only because none of us had a path in our dev environment containing a "." and didn't think to add a test case for it until the problem appeared. It's now fixed, and all tests pass in CVS. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
