php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #34552 Problems with __FILE__ and realpath()
Submitted: 2005-09-19 18:21 UTC Modified: 2007-01-07 01:00 UTC
Votes:71
Avg. Score:4.0 ± 1.1
Reproduced:48 of 53 (90.6%)
Same Version:18 (37.5%)
Same OS:20 (41.7%)
From: mmayer at blastwave dot org Assigned:
Status: No Feedback Package: Scripting Engine problem
PHP Version: 5CVS, 4CVS (2005-09-20) OS: Solaris 9, MacOSX, netBSD
Private report: No CVE-ID: None
View Developer Edit
 [2005-09-19 18:21 UTC] mmayer at blastwave dot org 
Description:
------------
This issue seems to be related to bug #27823, but broader in scope.

Using __FILE__ or realpath() on Solaris 9 SPARC (don't know about x86) doesn't work as expected if the scripts are located in a user's home-directory (~username/public_html) and the URL looks like http://my.example.com/~user/testscript.php. (Don't know if the '~' is actually causing the problem or if it's something else in this scenario).

Note that I *do* get the expected results from these scripts if I copy them to /opt/csw/apache2/share/htdocs/file_bug (i.e. underneath my web-server's doc-root) and access them through a URL like http://my.example.com/file_bug/<scriptname>.

In the failure case, __FILE__ returns './<filename>' instead of the full path if it is used in an included file.

realpath() returns an empty string instead of the actual path even though the file in question exists and the permissions are correct. (Regardless of whether realpath is used in an included file or directly.)



Reproduce code:
---------------
=== file.php: ===
<?php
print __FILE__;
print "<p>";
require("file2.php");
?>

=== file2.php: ===
<?php
print __FILE__;
?>

=== realpath.php: ===
<?php
print("realpath: '".realpath('realpath/test.txt')."'\n");
?>


Expected result:
----------------
file.php should print:
/home/markus/public_html/file_bug/file.php
/home/markus/public_html/file_bug/file2.php

realpath.php should print:
realpath: '/home/markus/public_html/file_bug/realpath/test.txt'

Actual result:
--------------
file.php prints:
/home/markus/public_html/file_bug/file.php
./file2.php

realpath.php prints:
realpath: ''

This is the directory layout (just to show that it's not a permission problem):
total 14
drwxr-xr-x   3 markus   staff  512 Sep 19 09:10 .
drwxr-xr-x  11 markus   staff 1536 Sep 15 11:07 ..
-rw-r--r--   1 markus   staff   60 Sep 14 13:41 file.php
-rw-r--r--   1 markus   staff   25 Sep 14 13:41 file2.php
drwxr-xr-x   2 markus   staff  512 Sep 19 09:07 realpath
-rw-r--r--   1 markus   staff   67 Sep 19 09:08 realpath.php

./realpath:
total 6
drwxr-xr-x   2 markus   staff  512 Sep 19 09:07 .
drwxr-xr-x   3 markus   staff  512 Sep 19 09:10 ..
-rw-r--r--   1 markus   staff    5 Sep 19 09:07 test.txt

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-09-20 11:02 UTC] sniper@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

See also bug #34514, can you reproduce this with CLI?
 [2005-09-20 18:43 UTC] mmayer at blastwave dot org 
No, I cannot reproduce this problem with CLI. Even 4.4.0 works in that case. 

I downloaded php5-latest.tar.gz.

$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 20 Sep 2005 16:31:46 GMT
Server: Apache/2.0.54 (Unix) DAV/2 PHP/5.1.0RC2-dev
[...]

Still getting the same results with the apache module that I saw for 4.4.0, so the problem is still there. CLI of 5.1.0RC2 works, however, just like CLI for 4.4.0.
 [2005-12-20 15:11 UTC] a dot l dot w dot kuijper at rug dot nl 
I CAN reproduce this bug in __FILE__ and realpath with the CLI version of PHP 4.4.0 installed on a netBSD 2.0.2 box with  apache 2.0.55.

I did exactly same as mmayer's example above (same files, same chmods) and got the same issue. 

This bug occurred when installing for Calendar 2. I hope you guys finally can resolve this mysterious bug.
 [2006-01-25 12:34 UTC] gdelafond at aquaray dot com 
I have the same bug on Mac OS X Server 10.4.3 with PHP 4.4.2 
when it is load as apache's module... but not when using the 
cli version.
 [2006-05-21 16:55 UTC] hakan at mysql dot com 
Problem still exists for me on Solaris 9 with PHP 5.1.4

On Linux with PHP 5.1.4 I get:
http://localhost/~hakan/test/file.php:

/home/hakan/.public_html/test/file.php
/home/hakan/.public_html/test/file2.php 

http://localhost/~hakan/test/realpath.php:
realpath: '/home/hakan/.public_html/test/realpath/test.txt'

On Solaris 9 with PHP 5.1.4 I get:
http://esslingen.homeunix.net/~hakan/test/file.php:

/home/hakan/.public_html/test/file.php
./file2.php

http://esslingen.homeunix.net/~hakan/test/realpath.php:
realpath: ''

Regards, Hakan
 [2006-06-30 15:24 UTC] kwerle at pobox dot com 
A quick scan will show this problem has been reported 
multiple tims.  I had been looking at #32967, but I can't 
change the state back to open, so here is where I'll report 
the true cause of the bug, and it's workaround.  Note that 
it has nothing to do with being in a user's home directory.

OK, I have created a trivial test case that displays the 
problem.  In short, if an ancestor directory (though not the 
direct parent) of a file is not readable (just executable), 
you will get this behavior.

Test case available at
http://shiftmanager.net/~kurt/test/
 [2006-07-21 07:03 UTC] T dot J dot Hunt at open dot ac dot uk 
I can confirm the previous has the correct diagnosis.

I was having this problem on MacOSX, and adding read 
permissions to all directories in the path fixed it for me.
 [2006-12-30 02:37 UTC] iliaa@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip
 [2007-01-07 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Apr 02 23:01:30 2025 UTC