php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login go to bug id or search bugs for
Bug #49039 Can't pass file name with subfolder name 3 characters or less
Submitted: 2009-07-23 19:00 UTC Modified: 2009-08-27 08:56 UTC
Votes: 5 3.4 ± 0.8 5 of 5 (100.0%) 5 (100.0%) 4 (80.0%)
From: sant9442 at gmail dot com Assigned: pajoye (profile)
Status: Not a bug Package: CGI/CLI related
PHP Version: 5.3.0 OS: win32 only - Windows
Private report: No CVE-ID: None
[2009-07-23 19:00 UTC] sant9442 at gmail dot com
Description:
------------
After upgrading to 5.3 from 5.2.6, we began to see "No input file specified" errors with working URLs: /pwe/helloworld.php

It was eventually discovered that renaming the pwe folder to something with 4 characters or more, then it would work.  A subfolder name with 3 characters or less failed:

Reproduce code:
---------------
A url would be:

/pwe/helloworld.php

where pwe is a subfolder off the web server root document folder:

d:\wc63\http

So the web server script mapping spawn basically did this which can be emulated manually:

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

This failed.  Rename  it to pwe1 and try:

d:\wc63\php-cgi.exe d:\wc63\http\pwe1\helloworld.php

and it should it work.

Expected result:
----------------
A page is displayed

Actual result:
--------------
"No Input File Specified"



## Pull Requests

Add a Pull Request

## History

[2009-07-23 19:09 UTC] sant9442 at gmail dot com
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."

[2009-07-23 19:22 UTC] jani@php.net
Please try using this snapshot:

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

For Windows:

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


[2009-07-23 19:25 UTC] pajoye@php.net
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...

[2009-07-23 20:11 UTC] sant9442 at gmail dot com
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
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
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
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
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

[2009-07-23 20:36 UTC] pajoye@php.net
It does not make sense to me.

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


[2009-07-23 21:07 UTC] sant9442 at gmail dot com
From: pajoye@php.net

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

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

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.

[2009-07-23 22:03 UTC] pajoye@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.


[2009-07-23 22:49 UTC] 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 23:02 UTC] 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

So PHP 5.3 symbolic link logic resolution logic seems broken :-)

--

[2009-07-23 23:02 UTC] pajoye@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:15 UTC] 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:

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-08-10 15:17 UTC] pajoye@php.net
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?

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.


[2009-08-10 15:18 UTC] pajoye@php.net
Which windows version do you use?

[2009-08-13 23:35 UTC] 1minus1 at gmail dot com
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. :)

[2009-08-15 12:27 UTC] sant9442 at gmail dot com
> Are you sure about the last line of the
> processmonitor log?

> 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!

[2009-08-15 13:18 UTC] mormegil at centrum dot cz
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.)

[2009-08-15 13:41 UTC] mormegil at centrum dot cz
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).

[2009-08-15 13:57 UTC] sant9442 at gmail dot com
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.

[2009-08-15 14:06 UTC] sant9442 at gmail dot com
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.

[2009-08-15 14:23 UTC] sant9442 at gmail dot com
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.

[2009-08-17 23:13 UTC] pajoye@php.net
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.

[2009-08-25 01:00 UTC] php-bugs at lists dot php dot net
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".

[2009-08-27 08:56 UTC] pajoye@php.net
Please see #48746. Same issue, all discussions/feedbacks will be followed there,

 Copyright © 2001-2019 The PHP Group All rights reserved. Last updated: Mon Aug 19 16:01:27 2019 UTC