Bug #48746 [Com]: Unable to browse directories within Junction Points
Edit report at https://bugs.php.net/bug.php?id=48746edit=1 ID: 48746 Comment by: php dot 10 dot davidsfcd at spamgourmet 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 Block user comment: N Private report: N New Comment: I have this issue with PHP 5.3.8, I'm running PHP under FastCGI under its own Security Principal. My PHP codebase uses CakePHP, when I run the project off a local HDD then the application works perfectly, but when I run the project off a directory that is an NTFS Symbolic Link to a UNC share on another server then PHP fails to load files specified by CakePHP. I've gone into the code and I can't see anything that would cause this to fail besides a regressive bug in PHP. I get the same problems with PHP 5.2.17 And with PHP 5.3.0 nothing works at all and PHP refuses to touch anything that goes through an NTFS junction point. Strange. Previous Comments: [2010-07-12 14:22:02] paj...@php.net It is the way it works on all platforms. It was only not support on windows with 5.2. However 5.3 and later support symlinks and junctions. Please read the documentation about symlink support in php and how they work. There is no bug here. [2010-07-12 14:16:14] M8R-jw2mu7 at mailinator dot com 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. ?php require_once( dirname($_SERVER['SCRIPT_FILENAME']). /../inc/config.php ); ? 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. [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? 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 https://bugs.php.net/bug.php?id=48746 -- Edit this bug report at https://bugs.php.net/bug.php?id=48746edit=1
Bug #48746 [Com]: Unable to browse directories within Junction Points
Edit report at http://bugs.php.net/bug.php?id=48746edit=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:
?php echo __FILE__; ?
In PHP 5.3.2:
C:\php-cli.532php.exe H:\www\directory\file.php
H:\www\directory\file.php
C:\php-cli.532php.exe H:\www\junction\file.php
H:\www\directory\file.php
C:\php-cli.532php.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:
?php
var_dump(lstat('H:\\www\\directory'));
var_dump(lstat('H:\\www\\junction'));
var_dump(lstat('H:\\www\\symlink'));
?
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=revisionrevision=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=revisionrevision=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=48746edit=1
Bug #48746 [Com]: Unable to browse directories within Junction Points
Edit report at http://bugs.php.net/bug.php?id=48746edit=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:
?php echo __FILE__; ?
In PHP 5.3.2:
C:\php-cli.532php.exe H:\www\directory\file.php
H:\www\directory\file.php
C:\php-cli.532php.exe H:\www\junction\file.php
H:\www\directory\file.php
C:\php-cli.532php.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:
?php
var_dump(lstat('H:\\www\\directory'));
var_dump(lstat('H:\\www\\junction'));
var_dump(lstat('H:\\www\\symlink'));
?
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=revisionrevision=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=revisionrevision=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=48746edit=1
Bug #48746 [Com]: Unable to browse directories within Junction Points
Edit report at http://bugs.php.net/bug.php?id=48746edit=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:
?php echo __FILE__; ?
In PHP 5.3.2:
C:\php-cli.532php.exe H:\www\directory\file.php
H:\www\directory\file.php
C:\php-cli.532php.exe H:\www\junction\file.php
H:\www\directory\file.php
C:\php-cli.532php.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:
?php
var_dump(lstat('H:\\www\\directory'));
var_dump(lstat('H:\\www\\junction'));
var_dump(lstat('H:\\www\\symlink'));
?
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=revisionrevision=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=48746edit=1
Bug #48746 [Com]: Unable to browse directories within Junction Points
Edit report at http://bugs.php.net/bug.php?id=48746edit=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.
?php
require_once( dirname($_SERVER['SCRIPT_FILENAME']). /../inc/config.php
);
?
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:
?php echo __FILE__; ?
In PHP 5.3.2:
C:\php-cli.532php.exe H:\www\directory\file.php
H:\www\directory\file.php
C:\php-cli.532php.exe H:\www\junction\file.php
H:\www\directory\file.php
C:\php-cli.532php.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:
?php
var_dump(lstat('H:\\www\\directory'));
var_dump(lstat('H:\\www\\junction'));
var_dump(lstat('H:\\www\\symlink'));
?
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=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746 Comment by: patrick dot boens at latosensu dot be Reported By: ddkees at illinois dot edu Status: No Feedback Bug Type: Directory function related Operating System: win32 only - Windows Server 2003 PHP Version: 5.3.0 Assigned To: pajoye New Comment: This bug is actually preventing us from using 5.3 at all! We have a framework that is used for ±60 sites; each of them contains a junction that points to 1 single instance of the framework. Previous Comments: [2009-09-22 01:00:00] 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-09-20 04:12:18] sant9442 at gmail dot com Hi, This is a note for the bug archives. I just discovered that the bug reported in #49039 which was merged with this bug entry, can also be reproduced when the web server spawning PHP-CGI.EXE incorrectly prepares the CGI environment string: PATH_INFO The correct official (IETF) standard definition is in RFC 3875: The Common Gateway Interface (CGI) Version 1.1: http://www.ietf.org/rfc/rfc3875 If PATH_INFO is incorrect, the function sapi_cgi_register_variables() sapi\cgi\cgi_main.c, which effectively does: PHP_SELF = SCRIPT_NAME + PATH_INFO will potentially cause the same No input file specified behavior we saw in bug #49039. The original bug #49039 report indicated a script in a sub-folder name with 3 letters, e.g.; /public/pwe/test.php would yield a file not found response. It was found if the server-side document root was a junction point, the no input file error was produced. c:\web\HTTP\public\pwe where C:\WEB\HTTP is a junction, like using SysInternals.com Junction.EXE utility: C: CD \WEB junction HTTP D:\WEB_SRC\HTTP_REV1.2.3.4 We internally use junctions in this way to test various versions of our html templates. Eventually it was determined by paj...@php.net the PHP 5.3 logic for resolving junctions has some issues to address and that is when I last left this issue until now. Recently, in an independent report related to PHP_SELF, we found out our web server was not creating the environment string PATH_INFO CGI correctly per RFC 3875. This serve issue was just fixed and after seeing how PHP expects PHP_SELF to be created using PATH_INFO, I was curious if the web server PATH_INFO fix also fixes #49039. Well, indeed it appears that it does fix it, even when the document root is a junction point. For the curious, our WEB SERVER first supported real CGI binary processes, no script maps, for example for a URI with: http://example.com/cgi-bin/applet.exe/file.txt?p1=v1 its parts are: SCRIPT_NAME = /cgi-bin/applet.exe QUERY_STRING= p1=v1 PATH_INFO = /file.txt if for the sake of example, the document root is: DOCUMENT_ROOT = c:\web\http then PATH_TRANSLATED is: PATH_TRANSLATED = c:\web\http\file.txt When script mapping support was added, including support for specific PHP's SCRIPT_FILENAME environment string, a bug was apparently introduced for creating PATH_INFO. So in an valid URI with a PHP script map: http://example.com/test.php/file.txt?p1=v2 Our web server correctly created: DOCUMENT_ROOT= c:\web\http SCRIPT_NAME = /test.php QUERY_STRING = p1=v1 SCRIPT_FILENAME = c:\web\http\test.php PATH_TRANSLATED = c:\web\http\file.txt but incorrectly created: PATH_INFO= /test.php/file.txt So when PHP-CGI started and created PHP_SELF in cgi_main.c PHP_SELF = SCRIPT_NAME + PATH_INFO its value was now: PHP_SELF = /test.php/test.php/file.txt thus the no input file found PHP response. As noted, this as fixed in our web sever, and it appears to resolve also bug #49039. I am sure inadvertingly the junction point issues were legit and being (and had been?) addressed, I am just nothing as it another possible reason caused by a web server not correctly implementing PATH_INFO per RFC 3875. [2009-09-14 18:49:29] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ The next snapshot (in 1-2h) will have the fix as in the tiny php build I provided earlier. [2009-09-14 18:46:57] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionrevision=288339 Log: - Fix #48746, improve fix to support all possible cases (see latest comment in the report)
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746 Comment by: sant9442 at gmail dot com Reported By: ddkees at illinois dot edu Status: Feedback Bug Type: Directory function related Operating System: win32 only - Windows Server 2003 PHP Version: 5.3.0 Assigned To: pajoye New Comment: Hi, This is a note for the bug archives. I just discovered that the bug reported in #49039 which was merged with this bug entry, can also be reproduced when the web server spawning PHP-CGI.EXE incorrectly prepares the CGI environment string: PATH_INFO The correct official (IETF) standard definition is in RFC 3875: The Common Gateway Interface (CGI) Version 1.1: http://www.ietf.org/rfc/rfc3875 If PATH_INFO is incorrect, the function sapi_cgi_register_variables() sapi\cgi\cgi_main.c, which effectively does: PHP_SELF = SCRIPT_NAME + PATH_INFO will potentially cause the same No input file specified behavior we saw in bug #49039. The original bug #49039 report indicated a script in a sub-folder name with 3 letters, e.g.; /public/pwe/test.php would yield a file not found response. It was found if the server-side document root was a junction point, the no input file error was produced. c:\web\HTTP\public\pwe where C:\WEB\HTTP is a junction, like using SysInternals.com Junction.EXE utility: C: CD \WEB junction HTTP D:\WEB_SRC\HTTP_REV1.2.3.4 We internally use junctions in this way to test various versions of our html templates. Eventually it was determined by paj...@php.net the PHP 5.3 logic for resolving junctions has some issues to address and that is when I last left this issue until now. Recently, in an independent report related to PHP_SELF, we found out our web server was not creating the environment string PATH_INFO CGI correctly per RFC 3875. This serve issue was just fixed and after seeing how PHP expects PHP_SELF to be created using PATH_INFO, I was curious if the web server PATH_INFO fix also fixes #49039. Well, indeed it appears that it does fix it, even when the document root is a junction point. For the curious, our WEB SERVER first supported real CGI binary processes, no script maps, for example for a URI with: http://example.com/cgi-bin/applet.exe/file.txt?p1=v1 its parts are: SCRIPT_NAME = /cgi-bin/applet.exe QUERY_STRING= p1=v1 PATH_INFO = /file.txt if for the sake of example, the document root is: DOCUMENT_ROOT = c:\web\http then PATH_TRANSLATED is: PATH_TRANSLATED = c:\web\http\file.txt When script mapping support was added, including support for specific PHP's SCRIPT_FILENAME environment string, a bug was apparently introduced for creating PATH_INFO. So in an valid URI with a PHP script map: http://example.com/test.php/file.txt?p1=v2 Our web server correctly created: DOCUMENT_ROOT= c:\web\http SCRIPT_NAME = /test.php QUERY_STRING = p1=v1 SCRIPT_FILENAME = c:\web\http\test.php PATH_TRANSLATED = c:\web\http\file.txt but incorrectly created: PATH_INFO= /test.php/file.txt So when PHP-CGI started and created PHP_SELF in cgi_main.c PHP_SELF = SCRIPT_NAME + PATH_INFO its value was now: PHP_SELF = /test.php/test.php/file.txt thus the no input file found PHP response. As noted, this as fixed in our web sever, and it appears to resolve also bug #49039. I am sure inadvertingly the junction point issues were legit and being (and had been?) addressed, I am just nothing as it another possible reason caused by a web server not correctly implementing PATH_INFO per RFC 3875. Previous Comments: [2009-09-14 18:49:29] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ The next snapshot (in 1-2h) will have the fix as in the tiny php build I provided earlier. [2009-09-14 18:46:57] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionrevision=288339 Log: - Fix #48746, improve fix to support all possible cases (see latest comment in the report) [2009-09-05 22:51:50] phpstuff at cresstone dot com That build fixed it for me. [2009-09-05 18:10:32] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionrevision=288085 Log: - add test for #48746 [2009-09-05 16:34:37] paj...@php.net Please try using: http://windows.php.net/downloads/qa/test/php-5.3.2-dev-Win32-VC9-x86.zip It is a striped down build (thread safe). Only CLI is available but no worry, it behaves
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
That build fixed it for me.
Previous Comments:
[2009-09-05 18:10:32] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionrevision=288085
Log: - add test for #48746
[2009-09-05 16:34:37] paj...@php.net
Please try using:
http://windows.php.net/downloads/qa/test/php-5.3.2-dev-Win32-VC9-x86.zip
It is a striped down build (thread safe). Only CLI is available but no
worry, it behaves the same than apache in TS mode.
[2009-09-04 20:59:28] phpstuff at cresstone dot com
Using junctions: is_file and file_exists are giving incorrect behavior
(false on files). is_dir as well, false on directories in the junction
and the junction itself.
The same functions are working well with symlinks.
If you need testing for this, you have mail.
[2009-09-04 20:45:25] paj...@php.net
@[4 Sep 8:20pm UTC] phpstuff at cresstone dot com
Using is_dir and is_file or file_exists and the cases you described,
does it work? (I don't think the filetype issue is related to what we
discuss here).
[2009-09-04 20:20:02] phpstuff at cresstone dot com
I was able replicate shoresofnowhere's behavior using windows 7...
I created a junction to a folder on another drive; running is_file() on
a file inside that junction returned false, as did is_dir(). Curious to
see what php thought it was looking at, I tested filetype(), which threw
an error.
I then tested symlinks in the same manner, and got good behavior.
Symlinks seem to be a good workaround for this issue.
Test log follows:
C:\mnt\testmklink /J junction_otherDrive f:\downloads
Junction created for junction_otherDrive === f:\downloads
C:\mnt\testmklink /D symlink_otherDrive f:\downloads
symbolic link created for symlink_otherDrive === f:\downloads
C:\mnt\testdir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.09.04 16.05DIR .
2009.09.04 16.05DIR ..
2009.09.04 16.05JUNCTION junction_otherDrive [f:\downloads]
2009.09.04 16.05SYMLINKD symlink_otherDrive [f:\downloads]
0 File(s) 0 bytes
4 Dir(s) 30,034,223,104 bytes free
C:\mnt\testphp -r var_dump(filetype('junction_otherdrive'));
PHP Warning: filetype(): Lstat failed for junction_otherdrive in
Command line code on line 1
Warning: filetype(): Lstat failed for junction_otherdrive in Command
line code on line 1
bool(false)
C:\mnt\testphp -r
var_dump(filetype('junction_otherdrive\php-5.2.0-win32-installer.msi'));
PHP Warning: filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Comm
and line code on line 1
Warning: filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Command l
ine code on line 1
bool(false)
C:\mnt\testphp -r var_dump(filetype('symlink_otherdrive'));
string(3) dir
C:\mnt\testphp -r
var_dump(filetype('symlink_otherdrive\php-5.2.0-win32-installer.msi'));
string(4) file
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: mats dot lindh at gmail dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Everything seems to work OK with a build from 2009-09-03. Thanks for
fixing the issue!
Previous Comments:
[2009-09-03 10:10:14] phpstuff at cresstone dot com
I'm getting good test behavior from the that snapshot. More tellingly,
the original script I've been trying to run is now working correctly.
Thanks.
[2009-09-02 23:26:04] paj...@php.net
I can't reproduce the problem with is_dir or is_file behave correctly,
however I think I found the problem and commited a fix.
I can reproduce the scandir one, same fix. I manually launched a build,
you can get the vc9-x86 here: http://is.gd/2OtDf (other snaps should be
online within 15mins).
[2009-09-02 22:59:59] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionrevision=287975
Log: - #48746, len includes null already
[2009-09-02 21:29:08] phpstuff at cresstone dot com
Using Windows 7 x64. It seems all files in my mounted volumes are being
treated as directories. (is_dir returns true, is_file returns false.)
Directory operations pointed at files seem to point back to the root of
the volume.
The following script:
echo dumping: scandir('mounted_volume')\n;
var_dump(scandir('mounted_volume'));
echo dumping: scandir('mounted_volume\\file1')\n;
var_dump(scandir('mounted_volume\file1'));
gives this output:
dumping: scandir('mounted_volume')
array(4) {
[0]=
string(12) $RECYCLE.BIN
[1]=
string(4) dir1
[2]=
string(4) dir2
[3]=
string(5) file1
}
dumping: scandir('mounted_volume\file1')
array(4) {
[0]=
string(12) $RECYCLE.BIN
[1]=
string(4) dir1
[2]=
string(4) dir2
[3]=
string(5) file1
}
Nesting does not seem to matter, eg:
scandir('mounted_volume\dir1\file_in_dir1'); gives the same output
Something else that's interesting... When I create the junction from a
drive letter, eg: mklink mounted_volume y: everything works perfectly,
files are files and dirs are dirs. It's only when I use the volume name
in the creation (mklink /J mounted_volume
\\?\Volume{feeac7c1-2ad0-11de-89bb-001fd0ae05ac}\) that I get this
strange behavior. Bizarre, but I swear I'm not making this up :)
[2009-09-02 10:35:32] paj...@php.net
Can't reproduce here. Which OS are you using for this test?
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: shoresofnowhere at gmail dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Sorry but the latest snapshot still has problems:
Dir directory
one.php file in dir directory
Dir2 junction in dir to dir3 on another drive
two.php file in dir3
in one.php:
is_file(./dir2/two.php) returns FALSE!
Working on XP SP3 under Apache 2.2.13
Previous Comments:
[2009-09-04 08:11:06] mats dot lindh at gmail dot com
Everything seems to work OK with a build from 2009-09-03. Thanks for
fixing the issue!
[2009-09-03 10:10:14] phpstuff at cresstone dot com
I'm getting good test behavior from the that snapshot. More tellingly,
the original script I've been trying to run is now working correctly.
Thanks.
[2009-09-02 23:26:04] paj...@php.net
I can't reproduce the problem with is_dir or is_file behave correctly,
however I think I found the problem and commited a fix.
I can reproduce the scandir one, same fix. I manually launched a build,
you can get the vc9-x86 here: http://is.gd/2OtDf (other snaps should be
online within 15mins).
[2009-09-02 22:59:59] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionrevision=287975
Log: - #48746, len includes null already
[2009-09-02 21:29:08] phpstuff at cresstone dot com
Using Windows 7 x64. It seems all files in my mounted volumes are being
treated as directories. (is_dir returns true, is_file returns false.)
Directory operations pointed at files seem to point back to the root of
the volume.
The following script:
echo dumping: scandir('mounted_volume')\n;
var_dump(scandir('mounted_volume'));
echo dumping: scandir('mounted_volume\\file1')\n;
var_dump(scandir('mounted_volume\file1'));
gives this output:
dumping: scandir('mounted_volume')
array(4) {
[0]=
string(12) $RECYCLE.BIN
[1]=
string(4) dir1
[2]=
string(4) dir2
[3]=
string(5) file1
}
dumping: scandir('mounted_volume\file1')
array(4) {
[0]=
string(12) $RECYCLE.BIN
[1]=
string(4) dir1
[2]=
string(4) dir2
[3]=
string(5) file1
}
Nesting does not seem to matter, eg:
scandir('mounted_volume\dir1\file_in_dir1'); gives the same output
Something else that's interesting... When I create the junction from a
drive letter, eg: mklink mounted_volume y: everything works perfectly,
files are files and dirs are dirs. It's only when I use the volume name
in the creation (mklink /J mounted_volume
\\?\Volume{feeac7c1-2ad0-11de-89bb-001fd0ae05ac}\) that I get this
strange behavior. Bizarre, but I swear I'm not making this up :)
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
I was able replicate shoresofnowhere's behavior using windows 7...
I created a junction to a folder on another drive; running is_file() on
a file inside that junction returned false, as did is_dir(). Curious to
see what php thought it was looking at, I tested filetype(), which threw
an error.
I then tested symlinks in the same manner, and got good behavior.
Symlinks seem to be a good workaround for this issue.
Test log follows:
C:\mnt\testmklink /J junction_otherDrive f:\downloads
Junction created for junction_otherDrive === f:\downloads
C:\mnt\testmklink /D symlink_otherDrive f:\downloads
symbolic link created for symlink_otherDrive === f:\downloads
C:\mnt\testdir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.09.04 16.05DIR .
2009.09.04 16.05DIR ..
2009.09.04 16.05JUNCTION junction_otherDrive [f:\downloads]
2009.09.04 16.05SYMLINKD symlink_otherDrive [f:\downloads]
0 File(s) 0 bytes
4 Dir(s) 30,034,223,104 bytes free
C:\mnt\testphp -r var_dump(filetype('junction_otherdrive'));
PHP Warning: filetype(): Lstat failed for junction_otherdrive in
Command line code on line 1
Warning: filetype(): Lstat failed for junction_otherdrive in Command
line code on line 1
bool(false)
C:\mnt\testphp -r
var_dump(filetype('junction_otherdrive\php-5.2.0-win32-installer.msi'));
PHP Warning: filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Comm
and line code on line 1
Warning: filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Command l
ine code on line 1
bool(false)
C:\mnt\testphp -r var_dump(filetype('symlink_otherdrive'));
string(3) dir
C:\mnt\testphp -r
var_dump(filetype('symlink_otherdrive\php-5.2.0-win32-installer.msi'));
string(4) file
Previous Comments:
[2009-09-04 18:32:33] paj...@php.net
Ignore my last two comments, it works perfectly using what you
describe. I was testing it from another VM where this junction did not
exist.
I added a include 'dir3/two.php' to one.php, two.php being a simple
echo two.php
The output:
C:\test\php53\debug_ts\php.exe -n one.php
two.php
bool(true)
C:\testjunction dir3
C:\test\dir3: JUNCTION
Substitute Name: e:\test
C:\testdir dir3
...
09/04/2009 07:33 PM24 two.php
1 File(s) 24 bytes
2 Dir(s) 202,975,232 bytes free
[2009-09-04 17:50:34] paj...@php.net
Please note that it is again a XP/2k3 only issue. Debugging/fixing now.
[2009-09-04 17:36:30] paj...@php.net
@shoresofnowhere at gmail dot com
ok, I can reproduce it now. I will come back as soon as I have a fix.
[2009-09-04 17:26:49] paj...@php.net
@shoresofnowhere at gmail dot com
I suppose you mean:
c:\Dir
|_ one.php
|_ Dir3 (junction to d:\dir)
|_ two.php
Using this constellation, here is my output on xp SP3:
C:\mntjunction dir3
Junction v1.05 - ..
...
C:\mnt\dir3: JUNCTION
Substitute Name: c:\test
C:\mnt\test\php53vc6ts\php.exe one.php
bool(true)
Are you sure:
- apache has been restarted after the update?
- the right version is used?
Can you try in CLI as well please?
[2009-09-04 11:44:08] shoresofnowhere at gmail dot com
Sorry but the latest snapshot still has problems:
Dir directory
one.php file in dir directory
Dir2 junction in dir to dir3 on another drive
two.php file in dir3
in one.php:
is_file(./dir2/two.php) returns FALSE!
Working on XP SP3 under Apache 2.2.13
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Using junctions: is_file and file_exists are giving incorrect behavior
(false on files). is_dir as well, false on directories in the junction
and the junction itself.
The same functions are working well with symlinks.
If you need testing for this, you have mail.
Previous Comments:
[2009-09-04 20:45:25] paj...@php.net
@[4 Sep 8:20pm UTC] phpstuff at cresstone dot com
Using is_dir and is_file or file_exists and the cases you described,
does it work? (I don't think the filetype issue is related to what we
discuss here).
[2009-09-04 20:20:02] phpstuff at cresstone dot com
I was able replicate shoresofnowhere's behavior using windows 7...
I created a junction to a folder on another drive; running is_file() on
a file inside that junction returned false, as did is_dir(). Curious to
see what php thought it was looking at, I tested filetype(), which threw
an error.
I then tested symlinks in the same manner, and got good behavior.
Symlinks seem to be a good workaround for this issue.
Test log follows:
C:\mnt\testmklink /J junction_otherDrive f:\downloads
Junction created for junction_otherDrive === f:\downloads
C:\mnt\testmklink /D symlink_otherDrive f:\downloads
symbolic link created for symlink_otherDrive === f:\downloads
C:\mnt\testdir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.09.04 16.05DIR .
2009.09.04 16.05DIR ..
2009.09.04 16.05JUNCTION junction_otherDrive [f:\downloads]
2009.09.04 16.05SYMLINKD symlink_otherDrive [f:\downloads]
0 File(s) 0 bytes
4 Dir(s) 30,034,223,104 bytes free
C:\mnt\testphp -r var_dump(filetype('junction_otherdrive'));
PHP Warning: filetype(): Lstat failed for junction_otherdrive in
Command line code on line 1
Warning: filetype(): Lstat failed for junction_otherdrive in Command
line code on line 1
bool(false)
C:\mnt\testphp -r
var_dump(filetype('junction_otherdrive\php-5.2.0-win32-installer.msi'));
PHP Warning: filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Comm
and line code on line 1
Warning: filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Command l
ine code on line 1
bool(false)
C:\mnt\testphp -r var_dump(filetype('symlink_otherdrive'));
string(3) dir
C:\mnt\testphp -r
var_dump(filetype('symlink_otherdrive\php-5.2.0-win32-installer.msi'));
string(4) file
[2009-09-04 18:32:33] paj...@php.net
Ignore my last two comments, it works perfectly using what you
describe. I was testing it from another VM where this junction did not
exist.
I added a include 'dir3/two.php' to one.php, two.php being a simple
echo two.php
The output:
C:\test\php53\debug_ts\php.exe -n one.php
two.php
bool(true)
C:\testjunction dir3
C:\test\dir3: JUNCTION
Substitute Name: e:\test
C:\testdir dir3
...
09/04/2009 07:33 PM24 two.php
1 File(s) 24 bytes
2 Dir(s) 202,975,232 bytes free
[2009-09-04 17:50:34] paj...@php.net
Please note that it is again a XP/2k3 only issue. Debugging/fixing now.
[2009-09-04 17:36:30] paj...@php.net
@shoresofnowhere at gmail dot com
ok, I can reproduce it now. I will come back as soon as I have a fix.
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
I'm getting good test behavior from the that snapshot. More tellingly,
the original script I've been trying to run is now working correctly.
Thanks.
Previous Comments:
[2009-09-02 23:26:04] paj...@php.net
I can't reproduce the problem with is_dir or is_file behave correctly,
however I think I found the problem and commited a fix.
I can reproduce the scandir one, same fix. I manually launched a build,
you can get the vc9-x86 here: http://is.gd/2OtDf (other snaps should be
online within 15mins).
[2009-09-02 22:59:59] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionrevision=287975
Log: - #48746, len includes null already
[2009-09-02 21:29:08] phpstuff at cresstone dot com
Using Windows 7 x64. It seems all files in my mounted volumes are being
treated as directories. (is_dir returns true, is_file returns false.)
Directory operations pointed at files seem to point back to the root of
the volume.
The following script:
echo dumping: scandir('mounted_volume')\n;
var_dump(scandir('mounted_volume'));
echo dumping: scandir('mounted_volume\\file1')\n;
var_dump(scandir('mounted_volume\file1'));
gives this output:
dumping: scandir('mounted_volume')
array(4) {
[0]=
string(12) $RECYCLE.BIN
[1]=
string(4) dir1
[2]=
string(4) dir2
[3]=
string(5) file1
}
dumping: scandir('mounted_volume\file1')
array(4) {
[0]=
string(12) $RECYCLE.BIN
[1]=
string(4) dir1
[2]=
string(4) dir2
[3]=
string(5) file1
}
Nesting does not seem to matter, eg:
scandir('mounted_volume\dir1\file_in_dir1'); gives the same output
Something else that's interesting... When I create the junction from a
drive letter, eg: mklink mounted_volume y: everything works perfectly,
files are files and dirs are dirs. It's only when I use the volume name
in the creation (mklink /J mounted_volume
\\?\Volume{feeac7c1-2ad0-11de-89bb-001fd0ae05ac}\) that I get this
strange behavior. Bizarre, but I swear I'm not making this up :)
[2009-09-02 10:35:32] paj...@php.net
Can't reproduce here. Which OS are you using for this test?
[2009-09-02 10:30:20] paj...@php.net
Oh my, I'm about to loose my last hair :)
But we are getting close now... back to code
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746 Comment by: phpstuff at cresstone dot com Reported By: ddkees at illinois dot edu Status: Feedback Bug Type: Directory function related Operating System: win32 only - Windows Server 2003 PHP Version: 5.3.0 Assigned To: pajoye New Comment: Everything seems to be working as of the latest snapshot, thanks. Previous Comments: [2009-09-01 17:54:20] paj...@php.net scandir has been fixed (not directly related to this issue) as well as the mounted points issues. All regressions should be fixed now. Can you give it a try please? The next snapshot will have the fixes. [2009-09-01 17:51:00] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionrevision=287950 Log: - #48746, revert previous about volume. Fix volume support to allow all mounted points (with or without drives) [2009-09-01 17:46:17] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionrevision=287949 Log: - #48746, fix regression in readdir/scandir and mounted points or junctions on windows [2009-08-30 13:06:33] paj...@php.net @shoresofnowhere at gmail dot com Not with symlink/link/etc. You can try it under unix as well: /var/www/dir1 /var/www/test.txt /var/www/dir2 /var/www/dir2/linktodir1 /var/www/dir2/test2.txt /var/www/dir2/linktodir1/t.php In t.php, ../test2.txt will fail because it will use dir1 as base direct. That's how it always worked, windows had only partial support for links (symbolic or hard) or junctions. It worked before but it was not correct (and not portable). [2009-08-30 13:00:44] shoresofnowhere at gmail dot com @ pajoye: Sorry, but i don't understand why the correct behaviour should be that of 5.3: dir1 directory subdir1 subdirectory of dir1 cfg.php file in dir1 dir2 directory cfg.php file in dir2 junction1 junction to subdir1 created in dir2 and i have in dir1/subdir1/file.php: require_once(../cfg.php); I expect that if i run dir1/subdir1/file.php i get require_once(dir1/cfg.php); BUT if i run dir2/subdir1/file.php i will get require_once(dir2/cfg.php); Could you please tell me why this would be wrong? File inclusions have always been relative to the path of the main php file that's executing... 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/48746 -- Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
sorry, found another mounted volume issue:
is_dir reutrns true when passed a file on a mounted volume.
Additionaly, chdir retruns true when passed that file.
eg: is_dir('c:\mounted_volume\image.jpg'); returns true. image.jpg is a
file and mounted_volume is a junction point mounted volume.
Previous Comments:
[2009-09-02 09:31:36] phpstuff at cresstone dot com
Everything seems to be working as of the latest snapshot, thanks.
[2009-09-01 17:54:20] paj...@php.net
scandir has been fixed (not directly related to this issue) as well as
the mounted points issues. All regressions should be fixed now. Can you
give it a try please? The next snapshot will have the fixes.
[2009-09-01 17:51:00] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionrevision=287950
Log: - #48746, revert previous about volume. Fix volume support to
allow all mounted points (with or without drives)
[2009-09-01 17:46:17] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionrevision=287949
Log: - #48746, fix regression in readdir/scandir and mounted points or
junctions on windows
[2009-08-30 13:06:33] paj...@php.net
@shoresofnowhere at gmail dot com
Not with symlink/link/etc. You can try it under unix as well:
/var/www/dir1
/var/www/test.txt
/var/www/dir2
/var/www/dir2/linktodir1
/var/www/dir2/test2.txt
/var/www/dir2/linktodir1/t.php
In t.php, ../test2.txt will fail because it will use dir1 as base
direct. That's how it always worked, windows had only partial support
for links (symbolic or hard) or junctions. It worked before but it was
not correct (and not portable).
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Using Windows 7 x64. It seems all files in my mounted volumes are being
treated as directories. (is_dir returns true, is_file returns false.)
Directory operations pointed at files seem to point back to the root of
the volume.
The following script:
echo dumping: scandir('mounted_volume')\n;
var_dump(scandir('mounted_volume'));
echo dumping: scandir('mounted_volume\\file1')\n;
var_dump(scandir('mounted_volume\file1'));
gives this output:
dumping: scandir('mounted_volume')
array(4) {
[0]=
string(12) $RECYCLE.BIN
[1]=
string(4) dir1
[2]=
string(4) dir2
[3]=
string(5) file1
}
dumping: scandir('mounted_volume\file1')
array(4) {
[0]=
string(12) $RECYCLE.BIN
[1]=
string(4) dir1
[2]=
string(4) dir2
[3]=
string(5) file1
}
Nesting does not seem to matter, eg:
scandir('mounted_volume\dir1\file_in_dir1'); gives the same output
Something else that's interesting... When I create the junction from a
drive letter, eg: mklink mounted_volume y: everything works perfectly,
files are files and dirs are dirs. It's only when I use the volume name
in the creation (mklink /J mounted_volume
\\?\Volume{feeac7c1-2ad0-11de-89bb-001fd0ae05ac}\) that I get this
strange behavior. Bizarre, but I swear I'm not making this up :)
Previous Comments:
[2009-09-02 10:35:32] paj...@php.net
Can't reproduce here. Which OS are you using for this test?
[2009-09-02 10:30:20] paj...@php.net
Oh my, I'm about to loose my last hair :)
But we are getting close now... back to code
[2009-09-02 10:12:22] phpstuff at cresstone dot com
sorry, found another mounted volume issue:
is_dir reutrns true when passed a file on a mounted volume.
Additionaly, chdir retruns true when passed that file.
eg: is_dir('c:\mounted_volume\image.jpg'); returns true. image.jpg is a
file and mounted_volume is a junction point mounted volume.
[2009-09-02 09:31:36] phpstuff at cresstone dot com
Everything seems to be working as of the latest snapshot, thanks.
[2009-09-01 17:54:20] paj...@php.net
scandir has been fixed (not directly related to this issue) as well as
the mounted points issues. All regressions should be fixed now. Can you
give it a try please? The next snapshot will have the fixes.
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: shoresofnowhere at gmail dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
@ pajoye:
Sorry, but i don't understand why the correct behaviour should be that
of 5.3:
dir1 directory
subdir1 subdirectory of dir1
cfg.php file in dir1
dir2 directory
cfg.php file in dir2
junction1 junction to subdir1 created in dir2
and i have in dir1/subdir1/file.php:
require_once(../cfg.php);
I expect that if i run dir1/subdir1/file.php i get
require_once(dir1/cfg.php);
BUT if i run dir2/subdir1/file.php i will get
require_once(dir2/cfg.php);
Could you please tell me why this would be wrong? File inclusions have
always been relative to the path of the main php file that's
executing...
Thanks!
Previous Comments:
[2009-08-30 11:17:07] paj...@php.net
Found the problems, the windows port of dirent (scandir) as well as
php_mkdir (used by mkdir()) lack a call to realpath, making them use the
current path with the standard API. It ends to use c:.
Testing the patch but it should do it for RC1 next Tuesday. You can
test the patch yourself by calling realpath manually:
scandir(realpath('mounted_volume')); or
mkdir(realpath('mounted_volume\\test34'));
Other files operations work as expected.
[2009-08-30 10:39:21] paj...@php.net
Using different drives work fine here (ie. G, Z or whatever else).
Did you test it using CLI? And running each test separately or using
one single script with all tests (stat cache will be used in this
case)?
Which windows version?
[2009-08-30 04:41:30] phpstuff at cresstone dot com
Hmmm. may have spoke too soon. Getting some weird results when working
with mounted volumes.
'C:\mnt\test\mounted_volume' is a junction mounted volume that is *not*
the system drive ie: not c:\
Take the following sequence of commands, working directory is
'C:\mnt\test\':
is_dir('mounted_volume');
Returns true, yay!
scandir('mounted_volume');
Here's the strange behavior; this command enumerates the root system
drive, c:\, rather than the correct pointed-to volume.
mkdir('mounted_volume\test34');
Returns true, but test32 is created on the incorrect volume: c:\test32
now exists
is_dir('mounted_volume\test34');
Returns FALSE, this is the correct behavior because the directory does
not exist in the correct location, but it is obviously inconsistent with
the above mkdir
unlink('mounted_volume\test34');
Throws a 'No such file or directory' warning. Appears to be looking in
the correct place.
My previous tests all used c:\ as the 'mounted volume' which is why I
didn't see this at first.
[2009-08-30 03:30:14] phpstuff at cresstone dot com
Latest snapshot give correct behavior for me. Thanks much.
[2009-08-30 02:09:06] paj...@php.net
@shoresofnowhere at gmail dot com
It is not correct, the correct behavior is relative to the target of
the link/junction, as it is on any other supported platforms with link
support. It was not the case in 5.2 but php did not support links
correctly (no link at all, and only partially for junction or mounted
drive).
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: shoresofnowhere at gmail dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Still not working correctly in latest snapshot: now if you have
dir1 directory
subdir1 subdirectory of dir1
dir2 directory
junction1 junction to subdir1 created in dir2
and from a file accessed as dir2/junction1/file.php you reference to
the ../ dir, you get to the dir1 directory, while the correct behaviour
is to get to dir2!
You can see the difference if you try this setup with 5.2.10, which
works ok.
Previous Comments:
[2009-08-29 12:23:01] paj...@php.net
Thanks for the testing! :)
Added support for mounted volumes (and path resolutions for them). The
next snapshots (5.3+) should have it.
[2009-08-29 12:21:48] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionrevision=287877
Log: - Fix #48746, mounted volume support resolution
[2009-08-27 19:37:08] phpstuff at cresstone dot com
Ok, this snap seems to get everything except mounted volumes for me.
test output is now:
C:\mnt\testphp phptest.php
directory: bool(true)
junction.exe junction: bool(true)
mklink junction:bool(true)
mounted volume: bool(false)
I've found 3 ways to create volume junction points on Win 7: Through
the mountvol command, thourgh the mklink command, and though the
diskmgmt.msc GUI. They all result in the same behavior.
I also just found that mklink can create symlinks to volumes, which,
alas, also fail. (symlinks to directories files work fine) 'dir'
command for symlinks vs. junctions to volumes looks like this:
2009.08.27 15.18SYMLINKD test2
[\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\]
2009.08.27 15.19JUNCTION test3
[\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\]
For the record, the following command sequence can be used to re-create
my test setup... c:\mnt c:\mnt\test are regular directories.
C:\mnt\testmkdir directory
C:\mnt\testjunction junction directory
Junction v1.05 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2007 Mark Russinovich
Systems Internals - http://www.sysinternals.com
Created: C:\mnt\test\junction
Targetted at: C:\mnt\test\directory
C:\mnt\testmklink /j mklink_junction directory
Junction created for mklink_junction === directory
C:\mnt\testmklink /j mounted_volume
\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\
Junction created for mounted_volume ===
\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\
C:\mnt\testdir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.08.27 15.29DIR .
2009.08.27 15.29DIR ..
2009.08.27 15.27DIR directory
2009.08.27 15.27JUNCTION junction
[\??\C:\mnt\test\directory]
2009.08.27 15.28JUNCTION mklink_junction
[C:\mnt\test\directory]
2009.08.27 15.29JUNCTION mounted_volume
[\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}
\]
2009.08.27 15.23 451 phptest.php
1 File(s)451 bytes
6 Dir(s) 28,746,731,520 bytes free
C:\mnt\testphp phptest.php
directory: bool(true)
junction.exe junction: bool(true)
mklink junction:bool(true)
mounted volume: bool(false)
Thanks for your work on this, unfortunately, my inability to keep track
of drive letters means I use a lot of mounted volumes...
[2009-08-27 09:50:22] paj...@php.net
And confirmed your last cases using Win7/Vista/2k8. In this case
junction are prepended with \??\. Fix applied, the next snap should
have it.
[2009-08-27 09:39:02] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionrevision=287800
Log: - Fix for #48746, fix mounted volume and junctions when used from
vista or later, they are actually prepended with \??\
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Latest snapshot give correct behavior for me. Thanks much.
Previous Comments:
[2009-08-30 02:09:06] paj...@php.net
@shoresofnowhere at gmail dot com
It is not correct, the correct behavior is relative to the target of
the link/junction, as it is on any other supported platforms with link
support. It was not the case in 5.2 but php did not support links
correctly (no link at all, and only partially for junction or mounted
drive).
[2009-08-29 20:34:10] shoresofnowhere at gmail dot com
Still not working correctly in latest snapshot: now if you have
dir1 directory
subdir1 subdirectory of dir1
dir2 directory
junction1 junction to subdir1 created in dir2
and from a file accessed as dir2/junction1/file.php you reference to
the ../ dir, you get to the dir1 directory, while the correct behaviour
is to get to dir2!
You can see the difference if you try this setup with 5.2.10, which
works ok.
[2009-08-29 12:23:01] paj...@php.net
Thanks for the testing! :)
Added support for mounted volumes (and path resolutions for them). The
next snapshots (5.3+) should have it.
[2009-08-29 12:21:48] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionrevision=287877
Log: - Fix #48746, mounted volume support resolution
[2009-08-27 19:37:08] phpstuff at cresstone dot com
Ok, this snap seems to get everything except mounted volumes for me.
test output is now:
C:\mnt\testphp phptest.php
directory: bool(true)
junction.exe junction: bool(true)
mklink junction:bool(true)
mounted volume: bool(false)
I've found 3 ways to create volume junction points on Win 7: Through
the mountvol command, thourgh the mklink command, and though the
diskmgmt.msc GUI. They all result in the same behavior.
I also just found that mklink can create symlinks to volumes, which,
alas, also fail. (symlinks to directories files work fine) 'dir'
command for symlinks vs. junctions to volumes looks like this:
2009.08.27 15.18SYMLINKD test2
[\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\]
2009.08.27 15.19JUNCTION test3
[\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\]
For the record, the following command sequence can be used to re-create
my test setup... c:\mnt c:\mnt\test are regular directories.
C:\mnt\testmkdir directory
C:\mnt\testjunction junction directory
Junction v1.05 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2007 Mark Russinovich
Systems Internals - http://www.sysinternals.com
Created: C:\mnt\test\junction
Targetted at: C:\mnt\test\directory
C:\mnt\testmklink /j mklink_junction directory
Junction created for mklink_junction === directory
C:\mnt\testmklink /j mounted_volume
\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\
Junction created for mounted_volume ===
\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\
C:\mnt\testdir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.08.27 15.29DIR .
2009.08.27 15.29DIR ..
2009.08.27 15.27DIR directory
2009.08.27 15.27JUNCTION junction
[\??\C:\mnt\test\directory]
2009.08.27 15.28JUNCTION mklink_junction
[C:\mnt\test\directory]
2009.08.27 15.29JUNCTION mounted_volume
[\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}
\]
2009.08.27 15.23 451 phptest.php
1 File(s)451 bytes
6 Dir(s) 28,746,731,520 bytes free
C:\mnt\testphp phptest.php
directory: bool(true)
junction.exe junction: bool(true)
mklink junction:bool(true)
mounted volume: bool(false)
Thanks for your work on this, unfortunately, my inability to keep track
of drive letters means I use a lot of mounted volumes...
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Hmmm. may have spoke too soon. Getting some weird results when working
with mounted volumes.
'C:\mnt\test\mounted_volume' is a junction mounted volume that is *not*
the system drive ie: not c:\
Take the following sequence of commands, working directory is
'C:\mnt\test\':
is_dir('mounted_volume');
Returns true, yay!
scandir('mounted_volume');
Here's the strange behavior; this command enumerates the root system
drive, c:\, rather than the correct pointed-to volume.
mkdir('mounted_volume\test34');
Returns true, but test32 is created on the incorrect volume: c:\test32
now exists
is_dir('mounted_volume\test34');
Returns FALSE, this is the correct behavior because the directory does
not exist in the correct location, but it is obviously inconsistent with
the above mkdir
unlink('mounted_volume\test34');
Throws a 'No such file or directory' warning. Appears to be looking in
the correct place.
My previous tests all used c:\ as the 'mounted volume' which is why I
didn't see this at first.
Previous Comments:
[2009-08-30 03:30:14] phpstuff at cresstone dot com
Latest snapshot give correct behavior for me. Thanks much.
[2009-08-30 02:09:06] paj...@php.net
@shoresofnowhere at gmail dot com
It is not correct, the correct behavior is relative to the target of
the link/junction, as it is on any other supported platforms with link
support. It was not the case in 5.2 but php did not support links
correctly (no link at all, and only partially for junction or mounted
drive).
[2009-08-29 20:34:10] shoresofnowhere at gmail dot com
Still not working correctly in latest snapshot: now if you have
dir1 directory
subdir1 subdirectory of dir1
dir2 directory
junction1 junction to subdir1 created in dir2
and from a file accessed as dir2/junction1/file.php you reference to
the ../ dir, you get to the dir1 directory, while the correct behaviour
is to get to dir2!
You can see the difference if you try this setup with 5.2.10, which
works ok.
[2009-08-29 12:23:01] paj...@php.net
Thanks for the testing! :)
Added support for mounted volumes (and path resolutions for them). The
next snapshots (5.3+) should have it.
[2009-08-29 12:21:48] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionrevision=287877
Log: - Fix #48746, mounted volume support resolution
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Ok, this snap seems to get everything except mounted volumes for me.
test output is now:
C:\mnt\testphp phptest.php
directory: bool(true)
junction.exe junction: bool(true)
mklink junction:bool(true)
mounted volume: bool(false)
I've found 3 ways to create volume junction points on Win 7: Through
the mountvol command, thourgh the mklink command, and though the
diskmgmt.msc GUI. They all result in the same behavior.
I also just found that mklink can create symlinks to volumes, which,
alas, also fail. (symlinks to directories files work fine) 'dir'
command for symlinks vs. junctions to volumes looks like this:
2009.08.27 15.18SYMLINKD test2
[\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\]
2009.08.27 15.19JUNCTION test3
[\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\]
For the record, the following command sequence can be used to re-create
my test setup... c:\mnt c:\mnt\test are regular directories.
C:\mnt\testmkdir directory
C:\mnt\testjunction junction directory
Junction v1.05 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2007 Mark Russinovich
Systems Internals - http://www.sysinternals.com
Created: C:\mnt\test\junction
Targetted at: C:\mnt\test\directory
C:\mnt\testmklink /j mklink_junction directory
Junction created for mklink_junction === directory
C:\mnt\testmklink /j mounted_volume
\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\
Junction created for mounted_volume ===
\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\
C:\mnt\testdir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.08.27 15.29DIR .
2009.08.27 15.29DIR ..
2009.08.27 15.27DIR directory
2009.08.27 15.27JUNCTION junction
[\??\C:\mnt\test\directory]
2009.08.27 15.28JUNCTION mklink_junction
[C:\mnt\test\directory]
2009.08.27 15.29JUNCTION mounted_volume
[\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}
\]
2009.08.27 15.23 451 phptest.php
1 File(s)451 bytes
6 Dir(s) 28,746,731,520 bytes free
C:\mnt\testphp phptest.php
directory: bool(true)
junction.exe junction: bool(true)
mklink junction:bool(true)
mounted volume: bool(false)
Thanks for your work on this, unfortunately, my inability to keep track
of drive letters means I use a lot of mounted volumes...
Previous Comments:
[2009-08-27 09:50:22] paj...@php.net
And confirmed your last cases using Win7/Vista/2k8. In this case
junction are prepended with \??\. Fix applied, the next snap should
have it.
[2009-08-27 09:39:02] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionrevision=287800
Log: - Fix for #48746, fix mounted volume and junctions when used from
vista or later, they are actually prepended with \??\
[2009-08-27 09:24:03] paj...@php.net
To do not miss a case again, can you please tell me how you create each
mounted volume or junction? If mnt is a mounted volume or not, etc.
Junction created with junction.exe works fine here on xp, 2k3, win7,
vista and 2k8, using normal parent directories (mounted volume or not).
For example (XP):
c:\mnt mounted volume (HDD)
c:\mnt\directory (mkdir directory)
c:\mnt\junction_abs (created with junction junction c:\mnt\directory)
c:\mnt\junction (created with junction junction directory from c:\mnt)
Using this script from c:\mnt\test (c:\mnt being a mounted volume):
?php
var_dump(file_exists('directory'));
var_dump(file_exists('junction_abs'));
var_dump(file_exists('junction'));
C:\mnt\test\php-sdk\snap_5_2\vc6\x86\php52\Debug\php.exe t.php
bool(true)
bool(true)
bool(true)
[2009-08-27 08:42:54] paj...@php.net
\??\ may be the cause (\\?\ is well documented not \??\). But I
wonder why junction.exe jucntion work just fine on our tests system (xp
and 2k3). Thanks for testing, I go back to codetest.
[2009-08-27 03:40:39] phpstuff at cresstone dot com
From my testing, this snapshot works for directory junction points
created with mklink. However still no go on mounted volumes or directory
junction points created with junction.exe.
Re-creating any faulting junctions with mklink seems like a good
workaround, but
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
From my testing, this snapshot works for directory junction points
created with mklink. However still no go on mounted volumes or directory
junction points created with junction.exe.
Re-creating any faulting junctions with mklink seems like a good
workaround, but mounted volumes are still left in the cold.
Looking at the output of the dir command, the only visible difference
between mklink and junction.exe is the prepended \??\, which is also
present on mounted volumes by necessity.
Full test log follows:
C:\mnt\testdir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.08.26 23.32DIR .
2009.08.26 23.32DIR ..
2009.08.11 16.35DIR directory
2009.08.11 14.47JUNCTION junction
[\??\C:\mnt\test\directory]
2009.08.20 13.26JUNCTION mklink_junction
[C:\mnt\test\directory]
2009.08.26 23.26JUNCTION mounted_volume
[\??\Volume{e13ba66a-14db-11de-8e96-001fd0ae05ac}
\]
2009.08.26 23.32 283 phptest.php
1 File(s)283 bytes
6 Dir(s) 28,765,544,448 bytes free
C:\mnt\testphp -v
PHP 5.3.1-dev (cli) (built: Aug 27 2009 03:52:14)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
C:\mnt\testtype phptest.php
?php
echo directory:\t\t; var_dump(file_exists(directory));
echo junction.exe junction:\t; var_dump(file_exists(junction));
echo mklink junction:\t; var_dump(file_exists(mklink_junction));
echo mounted volume:\t\t; var_dump(file_exists(mounted_volume));
?
C:\mnt\testphp phptest.php
directory: bool(true)
junction.exe junction: bool(false)
mklink junction:bool(true)
mounted volume: bool(false)
Previous Comments:
[2009-08-26 20:46:13] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-08-26 20:45:53] paj...@php.net
help if I comment in the right bug :) (reassigned)
[2009-08-26 20:44:50] paj...@php.net
Please follow #48746, same problem. I close (bogus) this bug to avoid
to have to split the info in too many reports.
[2009-08-26 20:44:06] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionrevision=287781
Log: - fix #48746, regression with file operaiton on path with
junctions
[2009-08-19 01:00:00] 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.
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
'mnt' is a regular directory. 'junction' was indeed pointing to the
root of a volume. However, I get exactly the same behavior if I create
the junction as a link to anouther directory via the junction.exe from
sysinternals. Again, this is a log from Windows 7 x64:
C:\mnt\testtype phptest.php
?php
var_dump(file_exists('junction'));
var_dump(file_exists('directory'));
?
C:\mnt\testdir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.08.10 16.11DIR .
2009.08.10 16.11DIR ..
2009.08.11 08.22DIR directory
2009.08.10 16.10JUNCTION junction
[\??\C:\mnt\test\directory]
2009.08.10 16.1182 phptest.php
1 File(s) 82 bytes
4 Dir(s) 24,210,726,912 bytes free
C:\mnt\testphp.exe phptest.php
bool(false)
bool(true)
Previous Comments:
[2009-08-11 06:32:56] paj...@php.net
Did you mount another drive in c:\mnt?
[2009-08-11 05:39:54] paj...@php.net
Sorry but I can't reproduce it on vista/win7/2k8 but only on 2k3 and
xp.
How exactly did you create the junctions on these platforms? It looks
like you create a junction to the root of another drive, right?
[2009-08-10 22:30:09] phpstuff at cresstone dot com
For what it's worth, I've reproduced the incorrect behavior on the
following OSes so far:
Windows 7 x64
Vista x64 SP2
Server 2003 x64 SP2
XP SP2
For other readers, these are the submitted issues I've found that may
be related to this bug:
http://bugs.php.net/bug.php?id=48778
http://bugs.php.net/bug.php?id=48746
http://bugs.php.net/bug.php?id=48975
http://bugs.php.net/bug.php?id=49039
[2009-08-10 21:41:37] paj...@php.net
and confirmed using XP SP3 as well.
For the record, get the junction command here:
http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx
[2009-08-10 20:23:35] paj...@php.net
Ok, seems to be 2k3 specific. The same setup works on 2k8/vista/win7.
Thanks for your feedback!
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
cgi executable does not seem to make a difference. This is a console
log of a test I just ran:
C:\mnt\testtype phptest.php
?php
var_dump(file_exists('junction'));
var_dump(file_exists('directory'));
?
C:\mnt\testdir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.08.10 16.11DIR .
2009.08.10 16.11DIR ..
2009.08.10 16.10DIR directory
2009.08.10 16.10JUNCTION junction
[\??\Volume{e13ba66a-14db-11de-8e96-001fd0ae05ac}\]
2009.08.10 16.1182 phptest.php
1 File(s) 82 bytes
4 Dir(s) 24,899,223,552 bytes free
C:\mnt\testphp.exe phptest.php
bool(false)
bool(true)
C:\mnt\testphp-cgi.exe phptest.php
X-Powered-By: PHP/5.3.0
Content-type: text/html
bool(false)
bool(true)
C:\mnt\test
Previous Comments:
[2009-08-10 15:40:17] paj...@php.net
@dr dot e dot sheppard at web dot de
Can you try using CLI/CGI please? As you can see below it works just
fine.
C:\Users\pierre\Documents\php-sdk\php53\vc9\x86dir
..
10.08.2009 17:36JUNCTION apps
[C:\Users\pierre\Documents\php-sdk\php53\vc9\x86\deps]
28.07.2009 00:59DIR deps
...
php.exe -r var_dump(file_exists('./apps'));
bool(true)
[2009-06-30 20:30:47] dr dot e dot sheppard at web dot de
This bug can easily be reproduced with the following scenario:
- change to a directory within your webserver's document root
- create a junction named apps pointing to the desired target within
the directory tree
- calling a php file (residing in parallel to the apps folder) with
the following code:
if(file_exists('./apps') === true){
echo 'yes!';
} else {
echo 'no!';
}
The result will be no!.
[2009-06-30 19:10:21] ddkees at illinois dot edu
The file structure looks like this. Junction points are followed by an
asterisk; that asterisk is _not_ a part of the folder's name within the
filesystem.
/
/includes
/includes/classes*
/includes/classes/.SwiftMailer
/includes/classes/course_websites
/includes/classes/directory
/includes/classes/faculty_awards*
/includes/classes/FirePHP
There are more folders than what's listed above, but that's enough to
give you the idea, I hope. If not, let me know.
As you can see from the code example above, we start the process in
/includes/classes and look for folders/files to identify class
definitions to include. Using this code and 5.3.0 this morning, we
found that, using the above list, only the faculty_awards junction point
would be identified as a directory when using is_dir() and when using
DirectoryIterator::isDir().
Here's a script to show what fails:
function find_directories($directory) {
$files = new DirectoryIterator($directory);
foreach($files as $file) {
if($file-isDot() || $file-getFilename()==_notes) continue;
echo Analyzing: $filebr;
var_dump($file-isDir());
echo Analysis Complete.brbr;
}
}
---
If we execute that function as follows:
find_directories($_SERVER[DOCUMENT_ROOT] . /includes/classes);
We would expect that all of the information listed above would result
in true. However, the actual results of that test were:
Analyzing: .SwiftMailer
bool(false) Analysis Complete
Analyzing: course_websites
bool(false) Analysis Complete
Analyzing: directories
bool(false) Analysis Complete
Analyzing: faculty_awards
bool(true) Analysis Complete
Analyzing: FirePHP
bool(false) Analysis Complete
[2009-06-30 17:58:46] paj...@php.net
Please provide a simple example to show what exactly does not work,
which function or method exactly and using which path:
- describe the directory tree you use and which parts of it are
junction
- provide a simple script to show which function(s) fail(s)
[2009-06-30 17:35:59] ddkees at illinois dot edu
It should be noted, that using 5.2.9-1 works exactly as expected.
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Assigned
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
For what it's worth, I've reproduced the incorrect behavior on the
following OSes so far:
Windows 7 x64
Vista x64 SP2
Server 2003 x64 SP2
XP SP2
For other readers, these are the submitted issues I've found that may
be related to this bug:
http://bugs.php.net/bug.php?id=48778
http://bugs.php.net/bug.php?id=48746
http://bugs.php.net/bug.php?id=48975
http://bugs.php.net/bug.php?id=49039
Previous Comments:
[2009-08-10 21:41:37] paj...@php.net
and confirmed using XP SP3 as well.
For the record, get the junction command here:
http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx
[2009-08-10 20:23:35] paj...@php.net
Ok, seems to be 2k3 specific. The same setup works on 2k8/vista/win7.
Thanks for your feedback!
[2009-08-10 20:17:32] phpstuff at cresstone dot com
cgi executable does not seem to make a difference. This is a console
log of a test I just ran:
C:\mnt\testtype phptest.php
?php
var_dump(file_exists('junction'));
var_dump(file_exists('directory'));
?
C:\mnt\testdir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.08.10 16.11DIR .
2009.08.10 16.11DIR ..
2009.08.10 16.10DIR directory
2009.08.10 16.10JUNCTION junction
[\??\Volume{e13ba66a-14db-11de-8e96-001fd0ae05ac}\]
2009.08.10 16.1182 phptest.php
1 File(s) 82 bytes
4 Dir(s) 24,899,223,552 bytes free
C:\mnt\testphp.exe phptest.php
bool(false)
bool(true)
C:\mnt\testphp-cgi.exe phptest.php
X-Powered-By: PHP/5.3.0
Content-type: text/html
bool(false)
bool(true)
C:\mnt\test
[2009-08-10 15:40:17] paj...@php.net
@dr dot e dot sheppard at web dot de
Can you try using CLI/CGI please? As you can see below it works just
fine.
C:\Users\pierre\Documents\php-sdk\php53\vc9\x86dir
..
10.08.2009 17:36JUNCTION apps
[C:\Users\pierre\Documents\php-sdk\php53\vc9\x86\deps]
28.07.2009 00:59DIR deps
...
php.exe -r var_dump(file_exists('./apps'));
bool(true)
[2009-06-30 20:30:47] dr dot e dot sheppard at web dot de
This bug can easily be reproduced with the following scenario:
- change to a directory within your webserver's document root
- create a junction named apps pointing to the desired target within
the directory tree
- calling a php file (residing in parallel to the apps folder) with
the following code:
if(file_exists('./apps') === true){
echo 'yes!';
} else {
echo 'no!';
}
The result will be no!.
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: dr dot e dot sheppard at web dot de
Reported By: ddkees at illinois dot edu
Status: Open
Bug Type: *Directory/Filesystem functions
Operating System: Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
This bug can easily be reproduced with the following scenario:
- change to a directory within your webserver's document root
- create a junction named apps pointing to the desired target within
the directory tree
- calling a php file (residing in parallel to the apps folder) with
the following code:
if(file_exists('./apps') === true){
echo 'yes!';
} else {
echo 'no!';
}
The result will be no!.
Previous Comments:
[2009-06-30 19:10:21] ddkees at illinois dot edu
The file structure looks like this. Junction points are followed by an
asterisk; that asterisk is _not_ a part of the folder's name within the
filesystem.
/
/includes
/includes/classes*
/includes/classes/.SwiftMailer
/includes/classes/course_websites
/includes/classes/directory
/includes/classes/faculty_awards*
/includes/classes/FirePHP
There are more folders than what's listed above, but that's enough to
give you the idea, I hope. If not, let me know.
As you can see from the code example above, we start the process in
/includes/classes and look for folders/files to identify class
definitions to include. Using this code and 5.3.0 this morning, we
found that, using the above list, only the faculty_awards junction point
would be identified as a directory when using is_dir() and when using
DirectoryIterator::isDir().
Here's a script to show what fails:
function find_directories($directory) {
$files = new DirectoryIterator($directory);
foreach($files as $file) {
if($file-isDot() || $file-getFilename()==_notes) continue;
echo Analyzing: $filebr;
var_dump($file-isDir());
echo Analysis Complete.brbr;
}
}
---
If we execute that function as follows:
find_directories($_SERVER[DOCUMENT_ROOT] . /includes/classes);
We would expect that all of the information listed above would result
in true. However, the actual results of that test were:
Analyzing: .SwiftMailer
bool(false) Analysis Complete
Analyzing: course_websites
bool(false) Analysis Complete
Analyzing: directories
bool(false) Analysis Complete
Analyzing: faculty_awards
bool(true) Analysis Complete
Analyzing: FirePHP
bool(false) Analysis Complete
[2009-06-30 17:58:46] paj...@php.net
Please provide a simple example to show what exactly does not work,
which function or method exactly and using which path:
- describe the directory tree you use and which parts of it are
junction
- provide a simple script to show which function(s) fail(s)
[2009-06-30 17:35:59] ddkees at illinois dot edu
It should be noted, that using 5.2.9-1 works exactly as expected.
[2009-06-30 17:19:27] ddkees at illinois dot edu
Description:
After updating this morning (June 30) to 5.3.0, our __autoload()
function failed to identify any classes located in subfolders of the
windows Junction Point which contains our class files.
Our __autoload() function is recursive, descending into the filesystem
looking for class files which match the one that we're trying to load.
However, since the /includes/classes folder is a Junction Point, only
other Junction Points return true when we use both is_dir() and
DirectoryIterator::isDir() to try and identify folders from files.
DirectoryIterator::isLink() also returns false.
However, if we change our __autoloader() to include files from the
source of the Junction Point, it works as expected, but this is only a
solution for a sub-set of the sites that are available on our server.
Reproduce code:
---
function __autoload($class) {
if(!function_exists(find_file)) {
function find_file($directory, $target) {
$dir = opendir($directory);
while(($file = readdir($dir))!==false) {
if($file == _notes || substr($file, 0,
1)==.) continue;
if(is_dir($directory . / . $file))
find_file($directory . / .
$file, $target);
elseif(basename($file, .php) == $target) {
require_once($directory . / . $file); return; }
}
}
}
find_file($_SERVER['DOCUMENT_ROOT'] . includes/classes,
strtolower($class));
}
Expected result:
The expected result is that starting from $_SERVER[DOCUMENT_ROOt] .
/includes/classes we
