Re: [HEADS UP] pecl/phar is now ext/phar

2008/5/14 Gregory Beaver <greg@chiaraquartet.net>: > 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 > 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!"