ID: 49039 Comment by: sant9442 at gmail dot com 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:
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. Previous Comments: ------------------------------------------------------------------------ [2009-08-15 14:06:53] 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 13:57:53] 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 13:41:14] 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:18:32] 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 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! ------------------------------------------------------------------------ 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
