ID: 49039
Updated by: paj...@php.net
Reported By: sant9442 at gmail dot com
-Status: Assigned
+Status: Feedback
Bug Type: CGI related
Operating System: win32 only - Windows
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Hi,
I was not able to reproduce this problem using:
F:\wc63>dir
<JUNCTION> http [F:\wc63\http-1234]
<DIR> http-1234
and the following call:
..\obj\Debug_TS\php-cgi.exe f:\wc63\http\pwe\t.php
X-Powered-By: PHP/5.3.1-dev
Content-type: text/html
included
F:\wc63\http-1234\pwe
script being: <?php echo "included\n"; print_r(getcwd());
Are you sure about the last line of the processmonitor log?
G:\files\php\php5-3-1-snapshot\pwephpinfo.php NAME NOT FOUND
As it is not only missing a back slash but the path itself is
completely wrong. It should have been:
D:\wc63\http\pwe\phpinfo.php
If you still get the same (wrong) results, please give me a way to
reproduce it. Using one directory tree (D:\wc63\http with
D:\wc63\http-1234 for example) and how exactly you call php.
Previous Comments:
------------------------------------------------------------------------
[2009-07-23 23:15:20] sant9442 at gmail dot com
Sure thing!
Btw, take a look at the last line for the 5.3 Process Monitor dump,
where it shows:
G:\files\php\php5-3-1-snapshot\pwephpinfo.php NAME NOT FOUND
Notice that it is missing a slash, so it seems its pointer movement is
off by one somewhere in the code, and I think this might be part of the
GPF that might occur as mentioned in bug #49040.
Thanks
------------------------------------------------------------------------
[2009-07-23 23:02:57] paj...@php.net
Thanks for the clear explanation :)
Ok, so it may be related to a bug with junctions and symlink in 5.3. I
will check it while working in the other related bugs (august, not
before :).
------------------------------------------------------------------------
[2009-07-23 23:02:25] sant9442 at gmail dot com
Small followup. I used SysInterna's ProcessMonitor and what I found,
that PHP 5.3 has a REVERSE ORDER LOOKUP of symbol link vs PHP 5.2.6
For example, for PHP 5.2.6, Process Monitor shows:
IRP_MJ_CREATE D:\ SUCCESS
IRP_MJ_DIRECTORY_CONTROL D:\wc63 SUCCESS
IRP_MJ_CLEANUP D:\ SUCCESS
IRP_MJ_CLOSE D:\ SUCCESS
IRP_MJ_CREATE D:\wc63 SUCCESS
IRP_MJ_DIRECTORY_CONTROL D:\wc63\http SUCCESS
IRP_MJ_CLEANUP D:\wc63 SUCCESS
IRP_MJ_CLOSE D:\wc63 SUCCESS
IRP_MJ_CREATE D:\wc63\http REPARSE
IRP_MJ_CREATE D:\wc63\http-4529 SUCCESS
IRP_MJ_DIRECTORY_CONTROL D:\wc63\http-4529\pwe SUCCESS
IRP_MJ_CLEANUP D:\wc63\http-4529 SUCCESS
IRP_MJ_CLOSE D:\wc63\http-4529 SUCCESS
IRP_MJ_CREATE D:\wc63\http-4529\pwe REPARSE
IRP_MJ_CREATE D:\wc63\http-4529\pwe SUCCESS
IRP_MJ_DIRECTORY_CONTROL D:\wc63\http-4529\pwe\phpinfo.php SUCCESS
In PHP 5.3, it does it reverse manner:
IRP_MJ_CREATE D:\wc63\http-4529\pwe REPARSE
IRP_MJ_CREATE D:\wc63\http-4529\pwe SUCCESS
IRP_MJ_DIRECTORY_CONTROL D:\wc63\http-4529\pwe\phpinfo.php SUCCESS
IRP_MJ_CLEANUP D:\wc63\http-4529\pwe SUCCESS
IRP_MJ_CLOSE D:\wc63\http-4529\pwe SUCCESS
IRP_MJ_CREATE D:\wc63\http REPARSE
IRP_MJ_CREATE D:\wc63\http-4529 SUCCESS
IRP_MJ_DIRECTORY_CONTROL D:\wc63\http-4529\pwe SUCCESS
IRP_MJ_CLEANUP D:\wc63\http-4529 SUCCESS
IRP_MJ_CLOSE D:\wc63\http-4529 SUCCESS
IRP_MJ_CREATE D:\wc63 SUCCESS
IRP_MJ_DIRECTORY_CONTROL D:\wc63\http SUCCESS
IRP_MJ_CLEANUP D:\wc63 SUCCESS
IRP_MJ_CLOSE D:\wc63 SUCCESS
IRP_MJ_CREATE D:\wc63\http SUCCESS
IRP_MJ_FILE_SYSTEM_CONTROL D:\wc63\http SUCCESS
IRP_MJ_CLEANUP D:\wc63\http SUCCESS
IRP_MJ_CLOSE D:\wc63\http SUCCESS
IRP_MJ_CREATE
G:\files\php\php5-3-1-snapshot\pwephpinfo.php NAME NOT FOUND
So PHP 5.3 symbolic link logic resolution logic seems broken :-)
--
------------------------------------------------------------------------
[2009-07-23 22:49:24] sant9442 at gmail dot com
> I find this whole report confusing. Let us try to make it simple.
Yes I agree, and thanks to your clue about junctions points and my
yesterday attempt to fool it with a junction pointing to a longer folder
name, I think I found the problem.
In our hosting server product installation folder, for example:
d:\wc63
we have a locked in sub folder name "HTTP"
d:\wc63\http
would be the so called "document root" folder.
Now, for my development or support, I create multiple HTTP-build# to
represent versions of our templates:
http-4521\
http-4522\
http-4525\
http-4529\
or I might have customer's copies of their HTTP folder
http-customer1\
http-customer2\
What I do is create a junction to symbolic name HTTP for example:
junction HTTP HTTP-4529
So in DOS, the DIR listing shows:
06/20/2009 09:22 PM <JUNCTION> http
07/23/2009 05:48 PM <DIR> http-4529
Now, I have a PWE (PHP for wildcat) script in
http-4529\pwe\phpinfo.php
which is linked to:
http\pwe\phpinfo.php
PHP 5.3 has a problem with this:
php.exe d:\wc63\http\pwe\phpinfo.php
Could not open input file: d:\wc63\http\pwe\phpinfo.php
php.exe d:\wc63\http-4529\pwe\phpinfo.php
HELLO PRIVATE
It appears PHP 5.3 has an issue with symbolic links,
This is not the case with 5.2.6.
g:\php526\php.exe d:\wc63\http\pwe\phpinfo.php
HELLO PRIVATE
Thanks
------------------------------------------------------------------------
[2009-07-23 22:03:31] paj...@php.net
I find this whole report confusing. Let us try to make it simple.
Please provide a single example where it fails with 5.3.0 and works
with 5.2.x, using a simple directory structure:
For example: c:\www\http\tst\t.php
Not using any junction, mklink or mounted directory.
Also without your custom extension.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/49039
--
Edit this bug report at http://bugs.php.net/?id=49039&edit=1
