Description
This is related to #115, but to do with the other Phar URI mapping function Phar::mount()
. This allows the application to bind an external file to a mount point within a Phar. I was testing this to see if the related fix also worked for mount points.
Here is the simple test stub that shows this:
<?php
# phar.readonly must be 0
$dir = dirname(__FILE__);
foreach (['A', 'B'] as $v) {
file_put_contents("$dir/temp{$v}.txt", "This is test file {$v}\n");
$stub = "<?php
Phar::interceptFileFuncs();
header('Content-Type: text/plain;');
Phar::mount('temp.txt', '$dir/temp{$v}.txt' );
require 'phar://this/index.php';
__HALT_COMPILER(); ?>";
$p = new Phar( "$dir/$v.phar.php", 0, 'this');
$p['index.php'] = "<?php
echo \"Entering Index $v.\n\";
include 'phar://this/hello.php';
include 'phar://this/temp.txt';
";
$p['hello.php'] = "Hello World says I am $v!\n";
$p->setStub($stub);
unset($p);
}
Run this in CLI mode with -d phar.readonly=0
and it creates the Phars {A,B}.phar.php
in the current directory. Executing in these in the CLI, eg. php A.phar.php
gives the output:
Entering Index A.
Hello World says I am A!
This is test file A
and similarly for the B variant. Likewise requesting http:://localhost:8888/A.phar.php
against a php -d opcache.enable=0 -S local:host:8888
works fine and the A and B variants can be randomly intermixed giving the expected return.
When repeated with OPcache enabled, A then B gives
- the A then B output with Xinchen's patch
- the A then A again without this patch showing the path issue when using phar #115 bug.
However, if you do A, B, A or A, A then Phar throws a PharException on the mount statement in subsequent invocations. This doesn't happen with OPcache disabled.
I'll track down the root-cause and post back. I suspect that the best way to address this and #115 is to review the entire URI mapping strategy within Phar and make it fully OPcache compatible by adding the correct hook function into zend.h
and chaining this through Phar. A 5.6 fix rather than 5.5.x.