open basedir - PHP: open_basedir allowed path

itemprop="text">

I have a few calls to
is_dir on a page. They have always worked no
problems.

A few days ago, the hosting
company upgraded PHP from 5.2 to 5.3. Since then, all my calls to
is_dir have resulted in the following error
(message):

Warning: is_dir():
            open_basedir restriction in
            effect.
File(/home/virtual/domain.com/public_html/galleries/img/002.JPG/)
is
            not within the allowed
            path(s):
(/home/virtual/domain.com:/home/virtual/_tmp)
in
            /home/virtual/domain.com/public_html/index.php on line
            201

This puzzles
me.

Clearly, according to the error
message (and php_info as well), the directory
/home/virtual/domain.com (with no trailing slash, so including
subdirectories) is included/enabled in open_basedir, and the
files that is_dir is trying to iterate through are all located
in subfolders under that folder. So why are they not within the allowed paths, then?
Clearly they are!

Strangely enough, this error
appears to only show up when is_dir
returns false, i.e., when the file is not a folder, but a
regular file. It seems to iterate through directories all right without throwing
errors.

Similar question posted previously here:
href="https://stackoverflow.com/questions/7586616/open-basedir-restriction-oddness">Open_basedir
restriction oddness (no solution
found).

Anyone have any
ideas?

(Note: Changing PHP settings is
not an option, as this is a shared host and I do not have any admin
access)

itemprop="text">

class="normal">Answer

There is
unfixed bug in PHP that is triggered when you open or check a path that have an existent
file as prefix, and not existent part as suffix. In your example there is existent part
/home/virtual/domain.com/public_html/galleries/img/002.JPG with
not existent suffix / (trailing slash in
path).

There is explanation that this is not a
bug: “This is expected behaviour. A non path that doesn't exists (the one with the
slash) is considered outside of the basedir.”, but I don't think so. This bug only
triggers if first part of path is an existent
file.

PHP
bugs: