Bug #28820 [Com]: Relative paths do not work with 'file://' stream wrapper

Edit report at https://bugs.php.net/bug.php?id=28820&edit=1 ID: 28820 Comment by: bilge at scriptfusion dot com Reported by: benjcarson at digitaljunkies dot ca Summary: Relative paths do not work with 'file://' stream wrapper Status: Wont fix Type: Bug Package: Filesystem function related Operating System: Linux PHP Version: 5CVS-2004-06-17 (dev) Block user comment: N Private report: N New Comment: Whether or not the docs did once explain that only absolute paths work with the file:// wrapper, that no longer appears to be the case. What's even less clear is that they support UNC paths by some mechanism. Previous Comments: ------------------------------------------------------------------------ [2004-06-18 00:38:30] benjcarson at digitaljunkies dot ca Thanks for the explanation & the doc fix. What you say makes perfect sense. ------------------------------------------------------------------------ [2004-06-18 00:29:52] pollita@php.net 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: 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 ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=28820&edit=1