php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #28820 Relative paths do not work with 'file://' stream wrapper
Submitted: 2004-06-17 22:39 UTC Modified: 2004-06-18 00:38 UTC
Votes:9
Avg. Score:4.0 ± 0.9
Reproduced:8 of 9 (88.9%)
Same Version:2 (25.0%)
Same OS:3 (37.5%)
From: benjcarson at digitaljunkies dot ca Assigned:
Status: Wont fix Package: Filesystem function related
PHP Version: 5CVS-2004-06-17 (dev) OS: Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: benjcarson at digitaljunkies dot ca
New email:
PHP Version: OS:

 

 [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


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-06-18 00:29 UTC] 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-18 00:38 UTC] benjcarson at digitaljunkies dot ca
Thanks for the explanation & the doc fix.  What you say makes perfect sense.
 [2017-11-02 00:24 UTC] bilge at scriptfusion dot com
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Nov 24 16:01:31 2024 UTC