ID: 49039 Updated by: paj...@php.net 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:
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. Previous Comments: ------------------------------------------------------------------------ [2009-08-15 14:23:02] 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-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.) ------------------------------------------------------------------------ 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
