|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2004-06-17 22:39 UTC] 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:
benj@mjollnir: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
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Wed Nov 05 10:00:02 2025 UTC |
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.