ID: 28820
User updated by: benjcarson at digitaljunkies dot ca
Reported By: benjcarson at digitaljunkies dot ca
Status: Wont fix
Bug Type: Filesystem function related
Operating System: Linux
PHP Version: 5CVS-2004-06-17 (dev)
New Comment:
Thanks for the explanation & the doc fix. What you say makes perfect
sense.
Previous Comments:
------------------------------------------------------------------------
[2004-06-18 00:29:52] [EMAIL PROTECTED]
On the note about parse_url(), no fopen() does not call parse_url to
determine wrapper usage.
The reason relative paths are not supported with the file:// wrapper
comes down to a compromise in how UNC paths are dealt with (and more
specifically how / are fuzzily interpreted as \ for windows
installations).
For Example:
file://foo/bar
Could be interpreted as a relative URI: foo/bar from the current
working directory, OR it could be interpreted as a UNC: \\foo\bar
(share `bar` on computer `foo`).
For this and a few internal reasons the file:// wrapper is limited to
absolute paths when called explicitly. For relative paths either use
realpath() {as you did in your report}, or omit the explicit naming of
the file wrapper.
I notice that the wording on http://www.php.net/wrappers regarding
relative paths is a touch ambiguous. I'll update that to show that
only absolute paths are supported when explicitly naming the wrapper.
------------------------------------------------------------------------
[2004-06-17 22:39:25] benjcarson at digitaljunkies dot ca
Description:
------------
When using fopen_wrappers, if a relative path is prepended with
'file://', fopen() and friends fail and emit a warning about remote
access being unsupported for file access. fopen() succeeds if
'file://' is omitted.
On a possibly related note, parse_url("file://test.php") returns
array(scheme => "file", host => "test.php"). I would imagine this is
the desired behaviour for remote protocols (e.g. 'http://php.net').
However, if the fopen wrapper for 'file://' is calling parse_url()
internally, this could explain why the error message is complaining
about remote hosts. I'm not familiar with the stream internals,
though, so I might be way off here...
And just in case anyone asks:
[EMAIL PROTECTED]:test$ php -r 'print_r(stream_get_wrappers());'
Array
(
[0] => php
[1] => file
[2] => http
[3] => ftp
[4] => compress.bzip2
[5] => compress.zlib
[6] => https
[7] => ftps
)
Reproduce code:
---------------
#!/usr/bin/php
<?php
// Note: 'test.php' exists in the current directory
$filename = "test.php";
$f1 = fopen($filename, "r"); // works
$f2 = fopen("file://". $filename, "r"); // fails
$f3 = fopen(realpath($filename), "r"); // works
$f4 = fopen("file://" . realpath($filename), "r"); // works
?>
Expected result:
----------------
(no output)
Actual result:
--------------
Warning: fopen(): remote host file access not supported,
file://test.php in ./file_get_contents.php on line 6
Warning: fopen(file://test.php): failed to open stream: no suitable
wrapper could be found in ./file_get_contents.php on line 6
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=28820&edit=1
