It should be noted that we spend 10 hours on this issue, first believing it was related to changed to the php.ini options

  ;doc_root =
  ;cgi.fix_pathinfo = 1
  cgi.force_redirect = 0

and CGI environment strings:

DOCUMENT_ROOT=d:\wc63\http
PATH_INFO=/pwe/helloworld.php
SCRIPT_NAME=/pwe/helloword.php
PATH_TRANSLATED=d:\wc63\http\pwe\helloworld.php
SCRIPT_FILENAME=d:\wc63\http\pwe\helloworld.php

which all research (googling) of "no input file specified" related to.

Reqardless of what we tried, it would not work until I discovered the 3 character folder name off the root folder was the problem.  Renaming it to 4 characters or more, solved the issue and that was discovered when all other URLS were working and we noticed the only difference was the 3 character length of the folder name.

This comment is mentioned so that time isn't wasted on the above issues related and possible reasons for "no input file specified."

Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

If any, try a 5.3 snapshot...

I am getting mixed results:

All these are called from my d:\wc63\http document root folder (not set in the ini, by switched there by the web server which also sets DOCUMENT_ROOT=d:\wc63\http :

D:\wc63\http>G:\files\php\php5.3-200907231830\php-cgi v:\wc5beta\http\wcphp\phpinfo.php
PHP Warning:  Unknown: failed to open stream: No such file or directory in Unknown on line 0
Status: 404 Not Found
X-Powered-By: PHP/5.3.1-dev
Content-type: text/html

No input file specified.

D:\wc63\http>G:\files\php\php5.3-200907231830\php-cgi v:\wc5beta\http\wcphp\phpinfo.php
PHP Warning:  Unknown: failed to open stream: No such file or directory in Unknown on line 0
Status: 404 Not Found
X-Powered-By: PHP/5.3.1-dev
Content-type: text/html

No input file specified.

D:\wc63\http>G:\files\php\php5.3-200907231830\php-cgi v:\wc5beta\http\pwe\phpinfo.php
PHP Warning:  Unknown: failed to open stream: No such file or directory in Unknown on line 0
Status: 404 Not Found
X-Powered-By: PHP/5.3.1-dev
Content-type: text/html

No input file specified.

D:\wc63\http>G:\files\php\php5.3-200907231830\php-cgi d:\wc63\http\public\pwe\phpinfo.php
X-Powered-By: PHP/5.3.1-dev
Content-type: text/html

hello


D:\wc63\http>G:\php526\php-cgi.exe d:\wc63\http\public\pwe\phpinfo.php
X-Powered-By: PHP/5.2.6
Content-type: text/html

hello


D:\wc63\http>G:\php526\php-cgi.exe d:\wc63\http\public\wcphp\phpinfo.php
Status: 404 Not Found
X-Powered-By: PHP/5.2.6
Content-type: text/html

No input file specified.

D:\wc63\http>G:\php526\php-cgi.exe d:\wc63\http\pwe\phpinfo.php
X-Powered-By: PHP/5.2.6
Content-type: text/html

HELLO PRIVATE

I don't wish to spend another ten hours on this trying to explain it.

As shown in the last example, none of these php-cgi.exe command line  issues appear in 5.2.6 or lesser version.  Only with 5.3.

Here is my analysis of the situation. In 5.3, there was a massive change to the parsing and file name resolution logic. There are issues with it.

Unfortunately, I lack the time to get into a windows recompiling project I can trace it down. The last time I did that I lost a tooth. :-)

Please also see bug #49040 which was found during the time trying to figure this out expecting it was related to the cgi ini settings and/or the env settings where were not the case.

thanks

It does not make sense to me.

Are these paths real paths or mounted (virtual or not), junctions, etc?

From: [email protected]

> It does not make sense to me.
> Are these paths real paths or mounted (virtual or not), 
> junctions, etc

Good question. All of the above was tried.

All this started with a programmer reported that our PHP extension PHP_WILDCAT.DLL called PWE (PHP Wildcat Extenson) for 5.2.6 was not working with 5.3.0. 

Our installed creates to sub folders for PWE sample scripts:

Server side (using d:\wc63 install folder of our hosting server)

   d:\wc63\http\pwe
   d:\wc63\http\public\pwe

In our system, http is inherently private (authentication is required)  with the excepton of the public\ folder.  So d:\wc6\http is the docuument root, and URL references will be:

   /pwe
   /public/pwe

In any case, after downloading 5.3-WIN32 and the source code for VC6  builds, I recompiled the PHP_WILDCAT.DLL extension  for 5.3. and the first test was:

   /pwe/phpinfo.php

to see the Wildcat! extension module info.  But I got the "No Input File Specified." error.  I copied it to the public\pwe folder and tried it:

   /public/pwe/phpinfo.php

and that worked.

That began a 10 hour adventure to see what was going on.  I focused on the the ini CGI settings which were:

  ;doc_root =
  cgi.force_redirect=0
  ;cgi.fix_pathinfo=1

and I wasted time trying all kinds of variations to no avail.  What I did finally realized that it wasn't related to our extension and could repeat the problem via the command line, by simply emulating what the web server would do:

  cd \wc63\http  
  d:\wc63\php\php-cgi.exe d:\wc63\http\pwe\phpinfo.php

d:\wc63\php would be where PHP installed, but it can be anywhere of course.  The result of above is:

Status: 404 Not Found
X-Powered-By: PHP/5.3.0
Content-type: text/html

No input file specified.

Now, I have PHP 5.2.6, also installed 

  d:\wc63\php526\php-cgi.exe d:\wc63\http\pwe\phpinfo.php

X-Powered-By: PHP/5.2.6
Content-type: text/html

HELLO PRIVATE

Now, all I have to do is use a folder that is not 3 characters, which I have one called WCPHP which I created and copied the script to:

    d:\wc63\php\php-cgi.exe d:\wc63\http\wcphp\phpinfo.php

Status: 404 Not Found
Content-type: text/html

HELLO PRIVATE

Anyway, once I saw it was the 3 character PWE folder I was thinking of how to fool it or change our installer to use longer folder names. I even tried a junction

   cd \wc63\http
   junction wcphp pwe

and it that didn't work which left me wondering if PHP-CGI.EXE was resolving the junction path.

This is all odd and rest assured, whether anyone can repeat it or not, the issue does exist. I hope some one can trace thru the logic.

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.

> 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

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 :-)

--

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 :).

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

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.

Which windows version do you use?

Hi!

I've just upgraded from PHP 5.2.10 to PHP 5.3.0 and had a problem 
similar to the discussed one: every attempt to load (with Apache) any 
php web page failed with the following error:

Warning: Unknown: failed to open stream: No such file or directory in 
Unknown on line 0
Fatal error: Unknown: Failed opening required 'C:/usr/www/test.php' 
(include_path='.;C:\php5\pear') in Unknown on line 0

After a while I happened to understand that the problem is related to 
symbolic links (directory junctions). On my system (Win XP SP3) the 
"C:\usr" folder is a junction to "D:\usr". The easiest way to 
reproduce this bug is by calling the CLI PHP interpreter.

C:\>type c:\usr\temp\test.php
<?="OK"?>

C:\>php c:\usr\temp\test.php
Could not open input file: c:\usr\temp\test.php

C:\>php d:\usr\temp\test.php
OK

--- 5 minutes later ---

Hmmm... I tried to reproduce the problem on some other "artificially 
created" folders and symlincs, and I happened to be unable to do so! 
And what is more, when I removed the "c:\usr" junction and re-created 
it - the problem (with Apache and the example above) disapeared! I 
don't know now how to interpret the problem, maybe that was a "bad 
link" (in some way), but the fact is: it *happened* and I've clearly 
seen it happening several times with 5.3 and not happening with 5.2.

At least I hope my report can help some googling "poor guys" like me 
to to get a clue on what is happening. :)

> 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

Correct, that is part of the bug I already mentioned - a lost slash. There seems to be a path parsing bug either +1 or -1, and the slash is lost. It is what it is in the processmon logs. If I recall, it was related to the length of the sub-folder. 3 or less caused a pointer offset issue. 4 or more was ok.

Also, as I indicated, it may be an intermittent issue, a pointer is off, and depending on the machine and OS, it could point to a low load memory (all zeros, no problem) or high load memory (all ones, a problem) or just random (intermittent).  That was determined because of the two machines testing was done (2000 and XP), I could reproduce under XP but not 2000.  Same code, same scripts, running from shared drives.  That tells me there is subtle memory/pointer issue as you can see with the processmon log indicated a parsed path with a missing slash.

> If you still get the same (wrong) results, please give me 
> a way to reproduce it. 

I wish I could give you more that I already did.  Right now, on my XP development box, I have to use PHP 5.2.6 with the directory structure I provided with the junction and 3 letter pwe sub folder.  Can't use 5.3 as we proceed with updates. We even had a small vote in our developers support forum if we should change the name of the PWE example folder name to something longer (WCPHP). But it was concluded that this is a PHP problem and we had the faith it will be eventually fixed. So no need to change documented material and distribution folder names.

I wish I had more time to debug the code, step by step, but the time I did when I was actively investigating it, I was able to step thru the debugger and see a path slash was lost at some point. I just don't recall exactly where in the code because there was a lot steps and what appeared some recursion.  Don't remember, but when the junction tip was  investigated, that is where I decided to use ProcessMon to see what was different between 5.2 and 5.3.  The lofic is definitely different - no doubt there.

But I can't tell ya is that is the issue or this path parsing issue is the root cause of the problem.

There are three ways to resolve it:

1) Don't use PHP 5.3
2) Don' use Junctions
3) Rename the PWE folder to something longer.

Given the evidence, I vote its the pointer problem  that may just alter the changed symbolic link logic or the changed itself produced the subtle pointer bug.

Who knows!

I hit this problem and decided to investigate a bit. The final result is that the reparse logic in tsrm_realpath_r is broken, or more specifically, incomplete. The problem (and the cause why some people are not able to reproduce the bug) is that there are more ways how to create a mount point on Windows, and it seems the exact representation of the parse point differs among those representations.

tsrm_realpath_r resolves reparse points using the print name of the reparse point. However, it seems that in my case, the reparse point does not have a print name at all:

  SubstituteNameOffset	0x0000	unsigned short
  SubstituteNameLength	0x0030	unsigned short
  PrintNameOffset	0x0032	unsigned short
  PrintNameLength	0x0000	unsigned short
  ReparseTarget	0x002a3a70 "\??\c:\temp\phptests\to\"	wchar_t [1]

As you can see, the reparse point only has its substitute name filled. I am used to creating reparse points using a simple MAKELINK.EXE utility (which I downloaded from http://www.codeproject.com/KB/winsdk/junctionpoints.aspx, I believe). This utility does not fill the print name, but the reparse point seems to work fine in all other programs, so this is probably a valid thing to do, and PHP should be also able to handle that.

Read http://brainrack.wordpress.com/2008/05/28/broken-and-ill-documented-api-for-windows-mount-points/ for more information on the various forms of mountpoints. (OBTW: You should probably use IsReparseTagMicrosoft, too.)

One more detail: if the link has been created using the built-in MKLINK command, PHP seems to work correctly (since MKLINK fills in both print name and substitute name), both for directory junction, and for a symbolic link.

Therefore, a workaround for this bug is to recreate the problematic reparse points using mklink (if you are on Vista/W2008/W7, XP did not have the command).

Good show. I have follow up with your links and also reup on junctions and moint points technical details. I have exclusively use SysInternal.com  junction.exe  (comes with C  source at the web site). I'm sure you know the infamous Mark Russinovich. No need to elaborate on this industy guru, So I might suggest to explore PHP windows junction operations with junction.exe as I am pretty sure (I trust) Mark's logics matches what is correctly technically expected under windows.  Put it this way, odds are good he is doing right. :-)

I do have a question? why does PHP even care about symbolic links?  Whats the purpose?  Why not just use the input file names as passed?, like it is expected?  Let the file system deal with it. Thats its purpose.  PHP seems to be breaking it apart to revert and obtain the physical path.  When I first saw that, I thought maybe it was doing for security purposes.

I have 5 bucks, Microsoft MKLINK for VISTA/2008/W7 was  written using Mark's Junction.C code as a basis. <g> Check this out:

http://technet.microsoft.com/en-us/magazine/2007.02.vistakernel.aspx

Also, why would PHP even came for this?  I just don't why.

After reading Mark's article, the man it probably wrote MKLINK from his junction.exe/c work, for a command link too, I have a recommendatin for PHP.

Since the new logic is for VISTA/W7/2008, I would highly suggest that PHP a) either no bother with this stuff, b) make it optional  or C) make sure it doesn't enforce VISTA/W7/2008 hard vs soft links in its design for general Windows operation.

It needs to take the lower ground with this or not at all. Then again, I don't see why it even cares about altering the intent of PHP developers or web operators with the scripts file names passed.  Links are suppose to be outside an PHP engine IMV.

There is a difference between junction.exe and mklink and that may cause what we have here.

We had to deal with symlink/junction (not under all circumstances) because of some path resolutions issues we have with symlinks, that's not specific to php either.

However a regression has been introduced with junctions (with junction.exe) and it will be fixed soon. 

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Please see #48746. Same issue, all discussions/feedbacks will be followed there,