Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37648
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
Message-ID: <482AED62.8050709@chiaraquartet.net>
Date: Wed, 14 May 2008 08:47:14 -0500
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: RQuadling@GoogleMail.com
CC: internals Mailing List <internals@lists.php.net>
References: <4828BA83.7050900@chiaraquartet.net>	 <48296276.4070103@daylessday.org> <10845a340805140431u52942409p1d4896c96d8ddb66@mail.gmail.com>
In-Reply-To: <10845a340805140431u52942409p1d4896c96d8ddb66@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar
From: greg@chiaraquartet.net (Gregory Beaver)

Richard Quadling wrote:
> 2008/5/13 Antony Dovgal <tony@daylessday.org>:
>   
>> 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