2008/5/14 Gregory Beaver <[EMAIL PROTECTED]>:
> 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
>

Thank you.

-- 
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to