I now believe that both of those if statements are wrong.  php3_fopen_with_path should always be run, because it is the only place that checks doc_root.  Experimenting shows that the PHP function fopen does not use doc_root, at least when configured the way I have it.  
If include_path is not set, php3_fopen_wrapper does the same thing as the alternative code blocks in these two statements, so those blocks are redundant.
(BTW, I do have safe_mode on, and open_basedir set to the same value as doc_root.)

Also, the check in php3_fopen_with_path for a relative file name is wrong, because it fails for files with names like ".cshrc" or "....", and it doesn't handle ".." either.

Here are patches to make it work the way it seems to me it should.

--- fopen-wrappers.c    1999/12/30 22:31:12     1.1.1.2
+++ fopen-wrappers.c    1999/12/31 21:26:54
@@ -194,16 +194,7 @@
        }
 #endif
 
-       if (options & USE_PATH && PG(include_path) != NULL) {
-               return php3_fopen_with_path(path, mode, PG(include_path), NULL);
-       } else {
-               if(!strcmp(mode,"r") || !strcmp(mode,"r+")) cm=0;
-               if (options & ENFORCE_SAFE_MODE && PG(safe_mode) && (!_php3_checkuid(path, cm))) {
-                       return NULL;
-               }
-               if (_php3_check_open_basedir(path)) return NULL;
-               return fopen(path, mode);
-       }
+       return php3_fopen_with_path(path, mode, PG(include_path), NULL);
 }
 
 #if CGI_BINARY || FHTTPD || USE_SAPI
@@ -324,8 +315,9 @@
        if (opened_path) {
                *opened_path = NULL;
        }
-       /* Relative path open */
-       if (*filename == '.') {
+       /* Relative path open; never use path */
+       if ((filename[0] == '.' && filename[1] == '/')
+               || (filename[0] == '.' && filename[1] == '.' && filename[2] == '/')) {
                if (PG(safe_mode) && (!_php3_checkuid(filename, cm))) {
                        return NULL;
                }
@@ -886,23 +878,8 @@
 
        } else {
                PLS_FETCH();
-
-               if (options & USE_PATH) {
-                       fp = php3_fopen_with_path((char *) path, mode, PG(include_path), NULL);
-               } else {
-                       int cm=2;
-                       if(!strcmp(mode,"r") || !strcmp(mode,"r+")) cm=0;
-                       if (options & ENFORCE_SAFE_MODE && PG(safe_mode) && (!_php3_checkuid(path, cm))) {
-                               fp = NULL;
-                       } else {
-                               if (_php3_check_open_basedir((char *) path)) {
-                                       fp = NULL;
-                               } else {
-                                       fp = fopen(path, mode);
-                               }
-                       }
-               }
 
+               fp = php3_fopen_with_path((char *) path, mode, PG(include_path), NULL);
                *issock = 0;
 
                return (fp);

I should also mention that I do not have include_path set, in my configuration.
Sorry the patch got mangled; netscape did that when I pasted it in.
I suggest you make the textarea box wider.

Here's a slightly more efficient patch for preventing relative paths from being searched for in include_path.

@@ -315,9 +315,10 @@
        if (opened_path) {
                *opened_path = NULL;
        }
-       /* Relative path open; never use path */
-       if ((filename[0] == '.' && filename[1] == '/')
-               || (filename[0] == '.' && filename[1] == '.' && filename[2] == '/')) {
+       /* Relative path; do not search for the file in "path" */
+       if (filename[0] == '.' &&
+               (filename[1] == '/'
+                || (filename[1] == '.' && filename[2] == '/'))) {
                if (PG(safe_mode) && (!_php3_checkuid(filename, cm))) {
                        return NULL;
                }

Please verify that it?s still happening using the latest version of PHP (release 4.0.1pl2 or CVS).

user feedback: still appearing

Have you tried latest CVS or snapshot from http://snaps.php.net lately?
If not, please try. And report back whether problem still exists.

--Jani

No feedback from user.

--Jani

Replying to the bug mail fails with "no route to host" for va.php.net, so I'll try posting my reply here.

Why don't the PHP developers check for themselves whether the problem is still there?  I'm tired of having to report PHP bugs 2 or 3 times because the developers wait 8 months before dealing with them.  You can read the code or diff it against the version I reported the bug in as well as I can.  I gave a precise analysis of the problem, which you should be able to understand.  You can see the on 08/01 I reported that the current version still had the problem.  Do you really want me to resubmit the bug report every month until it gets fixed?

There has been some fixes regarding doc_root problems recently.
Also check this url:

http://marc.theaimsgroup.com/?l=php-dev&m=96914235601714&w=2

I asked you to check the _latest_ CVS or snapshot because I couldn't
reproduce your problem with it.

And yes, if you have not heard of us for a long time you should update
your bug report, especially when there have been releases since you
submitted your report.

So, PLEASE read that document and try latest snapshot from 
http://snaps.php.net

and reply whether it solves your problem.  BTW. Next time, please 
tell us first WHAT the problem is and then submit a patch for it..not the
other way around.

--Jani


--Jani

This is fixed in PHP4.0.3pl1

--Jani