Bug #48746 [Com]: Unable to browse directories within Junction Points
Edit report at http://bugs.php.net/bug.php?id=48746&edit=1 ID: 48746 Comment by: M8R-jw2mu7 at mailinator dot com Reported by: ddkees at illinois dot edu Summary: Unable to browse directories within Junction Points Status: Closed Type: Bug Package: Directory function related Operating System: win32 only - Windows Server 2003 PHP Version: 5.3.0 Assigned To: pajoye New Comment: I don't know if at this point I should file a new defect. Let's say we have this structure: H:\www\site1\media\junction ( => I:\resources) Let's say we call page.php in a browser: $_SERVER['SCRIPT_FILENAME'] is 'h:/www/(etc.)' dirname(...) works OK. will yield an error: it does not try to load H:\www\site1\media\inc\config.php but I:\inc\config.php (I:\resources/../inc/config.php) Also, a realpath() on the included string returns false. Previous Comments: [2010-07-12 14:05:31] paj...@php.net The results in 5.3 are correct. ------------ [2010-07-12 13:58:09] M8R-jw2mu7 at mailinator dot com pajoye at php dot net: I get your point, but what about the lstat() part ? "Gathers the statistics of the file or symbolic link named by filename." Shouldn't it work for directory symlinks as well? ------------------------ [2010-07-12 13:52:28] M8R-jw2mu7 at mailinator dot com Replying to myself: I think this is by design. http://php.net/manual/en/language.constants.predefined.php says: __FILE__ The full path and filename of the file. If used inside an include, the name of the included file is returned. Since PHP 4.0.2, __FILE__ always contains an absolute path with symlinks resolved whereas in older versions it contained relative path under some circumstances. Maybe $_SERVER['SCRIPT_FILENAME'] should be used instead? ---------------- [2010-07-12 13:49:59] paj...@php.net M8R-jw2mu7 at mailinator dot com: That's expected. 5.2 did not support link or junction resolutions. ------------------------ [2010-07-12 13:43:37] M8R-jw2mu7 at mailinator dot com I don't know if the following behaviour regarding __FILE__ is intended, or if it's a regression due to the patch for this bug. Config test: Win 7, PHP 5.3.2 and 5.2.6 (VC6) I created the following structure: H:\www\directory H:\www\junction (=> H:\www\directory, created with junction.exe or any other tool) H:\www\symlink (=> directory, created with mklink.exe) The test case is file.php: In PHP 5.3.2: C:\php-cli.532>php.exe H:\www\directory\file.php H:\www\directory\file.php C:\php-cli.532>php.exe H:\www\junction\file.php H:\www\directory\file.php C:\php-cli.532>php.exe H:\www\symlink\file.php H:\www\directory\file.php This is not the case in, for instance, 5.2.6, which returns the correct paths. Haven't tested in the SAPIs if the result is the same. Can someone with win XP (pre-Vista) please try if the case with a junction yields the same output? Test case 2: All three outputs are the same, despite having different timestamps and using lstat. Once again, 5.2.6 gives correct results. 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/bug.php?id=48746 -- Edit this bug report at http://bugs.php.net/bug.php?id=48746&edit=1
Bug #48746 [Com]: Unable to browse directories within Junction Points
Edit report at http://bugs.php.net/bug.php?id=48746&edit=1 ID: 48746 Comment by: M8R-jw2mu7 at mailinator dot com Reported by: ddkees at illinois dot edu Summary: Unable to browse directories within Junction Points Status: Closed Type: Bug Package: Directory function related Operating System: win32 only - Windows Server 2003 PHP Version: 5.3.0 Assigned To: pajoye New Comment: pajoye at php dot net: I get your point, but what about the lstat() part ? "Gathers the statistics of the file or symbolic link named by filename." Shouldn't it work for directory symlinks as well? Previous Comments: [2010-07-12 13:52:28] M8R-jw2mu7 at mailinator dot com Replying to myself: I think this is by design. http://php.net/manual/en/language.constants.predefined.php says: __FILE__ The full path and filename of the file. If used inside an include, the name of the included file is returned. Since PHP 4.0.2, __FILE__ always contains an absolute path with symlinks resolved whereas in older versions it contained relative path under some circumstances. Maybe $_SERVER['SCRIPT_FILENAME'] should be used instead? [2010-07-12 13:49:59] paj...@php.net M8R-jw2mu7 at mailinator dot com: That's expected. 5.2 did not support link or junction resolutions. -------- [2010-07-12 13:43:37] M8R-jw2mu7 at mailinator dot com I don't know if the following behaviour regarding __FILE__ is intended, or if it's a regression due to the patch for this bug. Config test: Win 7, PHP 5.3.2 and 5.2.6 (VC6) I created the following structure: H:\www\directory H:\www\junction (=> H:\www\directory, created with junction.exe or any other tool) H:\www\symlink (=> directory, created with mklink.exe) The test case is file.php: In PHP 5.3.2: C:\php-cli.532>php.exe H:\www\directory\file.php H:\www\directory\file.php C:\php-cli.532>php.exe H:\www\junction\file.php H:\www\directory\file.php C:\php-cli.532>php.exe H:\www\symlink\file.php H:\www\directory\file.php This is not the case in, for instance, 5.2.6, which returns the correct paths. Haven't tested in the SAPIs if the result is the same. Can someone with win XP (pre-Vista) please try if the case with a junction yields the same output? Test case 2: All three outputs are the same, despite having different timestamps and using lstat. Once again, 5.2.6 gives correct results. [2009-10-25 22:21:03] paj...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-10-19 23:43:32] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=289782 Log: - MF53: Fix #48746, improve fix to support all possible cases (see latest comment in the report) 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/bug.php?id=48746 -- Edit this bug report at http://bugs.php.net/bug.php?id=48746&edit=1
Bug #48746 [Com]: Unable to browse directories within Junction Points
Edit report at http://bugs.php.net/bug.php?id=48746&edit=1 ID: 48746 Comment by: M8R-jw2mu7 at mailinator dot com Reported by: ddkees at illinois dot edu Summary: Unable to browse directories within Junction Points Status: Closed Type: Bug Package: Directory function related Operating System: win32 only - Windows Server 2003 PHP Version: 5.3.0 Assigned To: pajoye New Comment: Replying to myself: I think this is by design. http://php.net/manual/en/language.constants.predefined.php says: __FILE__ The full path and filename of the file. If used inside an include, the name of the included file is returned. Since PHP 4.0.2, __FILE__ always contains an absolute path with symlinks resolved whereas in older versions it contained relative path under some circumstances. Maybe $_SERVER['SCRIPT_FILENAME'] should be used instead? Previous Comments: [2010-07-12 13:49:59] paj...@php.net M8R-jw2mu7 at mailinator dot com: That's expected. 5.2 did not support link or junction resolutions. [2010-07-12 13:43:37] M8R-jw2mu7 at mailinator dot com I don't know if the following behaviour regarding __FILE__ is intended, or if it's a regression due to the patch for this bug. Config test: Win 7, PHP 5.3.2 and 5.2.6 (VC6) I created the following structure: H:\www\directory H:\www\junction (=> H:\www\directory, created with junction.exe or any other tool) H:\www\symlink (=> directory, created with mklink.exe) The test case is file.php: In PHP 5.3.2: C:\php-cli.532>php.exe H:\www\directory\file.php H:\www\directory\file.php C:\php-cli.532>php.exe H:\www\junction\file.php H:\www\directory\file.php C:\php-cli.532>php.exe H:\www\symlink\file.php H:\www\directory\file.php This is not the case in, for instance, 5.2.6, which returns the correct paths. Haven't tested in the SAPIs if the result is the same. Can someone with win XP (pre-Vista) please try if the case with a junction yields the same output? Test case 2: All three outputs are the same, despite having different timestamps and using lstat. Once again, 5.2.6 gives correct results. [2009-10-25 22:21:03] paj...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-10-19 23:43:32] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=289782 Log: - MF53: Fix #48746, improve fix to support all possible cases (see latest comment in the report) [2009-10-09 14:05:14] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=289414 Log: - Merge Fix for #48746, improve fix for junctions/symlink/etc. 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/bug.php?id=48746 -- Edit this bug report at http://bugs.php.net/bug.php?id=48746&edit=1
Bug #48746 [Com]: Unable to browse directories within Junction Points
Edit report at http://bugs.php.net/bug.php?id=48746&edit=1 ID: 48746 Comment by: M8R-jw2mu7 at mailinator dot com Reported by: ddkees at illinois dot edu Summary: Unable to browse directories within Junction Points Status: Closed Type: Bug Package: Directory function related Operating System: win32 only - Windows Server 2003 PHP Version: 5.3.0 Assigned To: pajoye New Comment: I don't know if the following behaviour regarding __FILE__ is intended, or if it's a regression due to the patch for this bug. Config test: Win 7, PHP 5.3.2 and 5.2.6 (VC6) I created the following structure: H:\www\directory H:\www\junction (=> H:\www\directory, created with junction.exe or any other tool) H:\www\symlink (=> directory, created with mklink.exe) The test case is file.php: In PHP 5.3.2: C:\php-cli.532>php.exe H:\www\directory\file.php H:\www\directory\file.php C:\php-cli.532>php.exe H:\www\junction\file.php H:\www\directory\file.php C:\php-cli.532>php.exe H:\www\symlink\file.php H:\www\directory\file.php This is not the case in, for instance, 5.2.6, which returns the correct paths. Haven't tested in the SAPIs if the result is the same. Can someone with win XP (pre-Vista) please try if the case with a junction yields the same output? Test case 2: All three outputs are the same, despite having different timestamps and using lstat. Once again, 5.2.6 gives correct results. Previous Comments: [2009-10-25 22:21:03] paj...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-10-19 23:43:32] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=289782 Log: - MF53: Fix #48746, improve fix to support all possible cases (see latest comment in the report) [2009-10-09 14:05:14] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=289414 Log: - Merge Fix for #48746, improve fix for junctions/symlink/etc. [2009-10-02 15:14:55] paj...@php.net Damned, wrong id :) That's the correct bug to follow. It is fixed in SVN and has to be mrerged to PHP_5_3_1 (branch for 5.3.1). Assigned back to me so it won't move to "no feedback" (stupid feature). [2009-10-02 15:13:32] paj...@php.net And let close that one as well. Please see #48746. Same issue, all discussions/feedbacks will be followed there. 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/bug.php?id=48746 -- Edit this bug report at http://bugs.php.net/bug.php?id=48746&edit=1