Can someone please finally take a look at this?

Why hasn't this bug been resolved? It's nearly 2 years old...

This bug is also present in php 5.4...

The patch open-basedir-without-realpath would fix this issue, but
it might have security implications or other undesired side
effects.

Any news on this one? Edge case but still :)

Considering the amount of closely related bug reports[1], I
wouldn't necessarily call that an edge case, Pierre. :)

I'll make a PR based on my patch with some tests, if no one beats
me to it.

[1] I've assembled a maybe non-exhaustive list in
<http://news.php.net/php.internals/86301>.

Broken since 5.3.0, see https://3v4l.org/paO83

Why isn't this bug fixed yet?
It was detected in 2013 or even before. And already passed 5 years... 

I trying the following example with PHP 7 and I'm getting exactly the same error.

<?
ini_set("open_basedir", __DIR__);
file_put_contents(__DIR__ . "/foo.txt", "bar");
echo "EXISTS:".file_exists(__DIR__ . "/foo.txt/");
?>

Error: PHP Warning:  file_exists(): open_basedir restriction in effect. File(/var/www/html/test/foo.txt/) is not within the allowed path(s): (/var/www/html/test) in /var/www/html/test/test.php on line 4

Can you please fix this and let me know please?
Thanks

We're seeing this in all the PHP versions we use (5.6, 7.0, 7.1, 7.2).

Literally spent hours trying to understand why we have these warning even that the paths are allowed in the open_basedir directive.

Finally it was because the parent dir of a path was in fact a file and not a dir.

The warning message is really misleading...

It would really be nice to fix this

Please fix asap, reported by many users. Thank you.

Cool, a bug described in 2010 not even fixed in PHP 8.0RC3.
That's a statement!

cat a.php
<?
ini_set("open_basedir","/home/naox/public_html/test");
mkdir("/home/naox/public_html/test");

php a.php

Warning: mkdir(): open_basedir restriction in effect. File(/home/naox/public_html/test) is not within the allowed path(s): (/home/naox/public_html/test) in /home/naox/public_html/naox.vipserv.org/a.php on line 3

> […] but it might have security implications […]

Indeed, it would.  Passing FALSE as 5th parameter to
expand_filepath_with_mode() actually means CWD_EXPAND, and that
would not resolve symlinks.

A possible solution for the issue would be to change
php_check_specific_open_basedir() so that it returns different
values for failure (currently it always returns -1, what should
actually be FAILURE), so that the caller could distinguish between
an actual open_basedir violation, and an invalid path (as is the
case here; files can't have subdirectories).  However. the functon
is exported, so changing the result values would be a BC break
(and a rather delicate at that).

An alternative would be to introduce another function, say
php_check_specific_open_basedir_ex() which gives more detailed
failure information, but frankly, why not simply change the error
message?

Of course, one may argue that "file checking" functions, such as
is_readable() or is_file() should not warn at all, but simply
rreturn false, but again, that would require to modify the
existing funtion, or to introduce a new one, because currently
there is no such distintion when checking for potential
open_basedir violations.  A global flag to the rescue?

> why not simply change the error
> message?

because any message is a problem to begin with and more important: in most of the cases you get a message that a path which is obviously within open_basedir isn't  

you could even check that and be silent given that when i see that as human with the blink of an exe why shouldn't a computer?

> Of course, one may argue that "file checking" functions, such as
> is_readable() or is_file() should not warn at all, but simply
> rreturn false, but again, that would require to modify the
> existing funtion

and *that* is the point after decades where this annoying behavior exists - wenn i ask from inside the application if a file exists i don't care why i can't reach it (don't exist, no permissions, open_basedir)

especially on systems with error_reporting E_ALL on purpose and sending twice per hours log collections with a "fix it" policy it's really annoying and when you also have a don't use @ for error supression policy you are doomed

Warning: file_exists(): open_basedir restriction in effect. File(ReallySimpleCaptcha.php) is not within the allowed path(s): (/www/wwwroot/itpingo.com/:/tmp/) in /www/wwwroot/itpingo.com/wp-content/plugins/minimal-coming-soon-maintenance-mode/framework/public/include/misc/geoip/autoload.php on line 39