ID: 49039 Comment by: mormegil at centrum dot cz Reported By: sant9442 at gmail dot com Status: Feedback Bug Type: CGI related Operating System: win32 only - Windows PHP Version: 5.3.0 Assigned To: pajoye New Comment:
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.) Previous Comments: ------------------------------------------------------------------------ [2009-08-15 12:27:35] sant9442 at gmail dot com > 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! ------------------------------------------------------------------------ [2009-08-13 23:35:47] 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-10 15:18:09] paj...@php.net Which windows version do you use? ------------------------------------------------------------------------ [2009-08-10 15:17:13] paj...@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? 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. ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ 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
