|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #45421 Runtime equivilant of __FILE__
Submitted: 2008-07-02 21:53 UTC Modified: 2011-01-24 23:52 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: rpeters at icomproductions dot ca Assigned:
Status: Not a bug Package: *General Issues
PHP Version: 5.2.6 OS: CentOS 4.3
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: rpeters at icomproductions dot ca
New email:
PHP Version: OS:


 [2008-07-02 21:53 UTC] rpeters at icomproductions dot ca
Since __FILE__ is defined at compile-time, it means that files that "change location" (eg: are renamed, or hard-linked with multiple filenames) execute incorectly when pre-compiled.

This is especially evident with op-code caches such as APC.

So __FILE__ either needs to be determined at runtime, or a runtime accessible alternative needs to be provided.

I propose $_SERVER['PHP_FILE'], and would like documentation updated to recommend people use it rather than __FILE__.

Obviously, __DIR__ would need the $_SERVER['PHP_DIR'] variable for the same reasons.

Reproduce code:

require(__DIR__ . '/testDest.php');

/2/test.php created by "cp -l ../1/test.php"

echo 1;

echo 2;


require($_SERVER['PHP_DIR'] . '/testDest.php');

/2/test.php created by "cp -l ../1/test.php"

echo 1;

echo 2;

Expected result:
/1/test.php displays "1", and /2/test.php displays "2"

Actual result:

When running APC, both scripts will return the results of whichever one you hit first.


When running APC, /1/test.php displays "1", and /2/test.php displays "2"


apc_auto_hardlinks_for_php_5.3.5.diff (last revision 2011-04-27 08:27 UTC by simpcl2008 at gmail dot com)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-07-02 21:54 UTC] rpeters at icomproductions dot ca
Related to APC Bug# 14055
 [2008-07-02 22:00 UTC]
There is nothing wrong with PHP here, its working as intended. I suggest you stop relying on __FILE__ if you intend to use an opcode cache.
 [2008-07-02 22:08 UTC] rpeters at icomproductions dot ca
I would love to stop "relying on __FILE__", which is why I introduced this feature request...???

If you have an existing way of finding the containing directory of a file being run via an include (as desired in the example code) that does not rely on __FILE__, please provide it, none of the documentation or attached comments suggest any alternatives, and in fact strongly recommend using __FILE__.

In my application, we have one file included from all others, in many different directories, making the working directory rather random, and unrelated to the containing directory of the centralized file, so __FILE__ and/or a runtime equivalent are necessary.
 [2008-07-02 22:56 UTC]
realpath($_SERVER['PHP_SELF']) but that's mainly for the executing file.

You're asking us to add a feature for what is essentially a problem with the opcode cache, there is no problem with PHP in this case.
 [2008-07-02 23:03 UTC] rpeters at icomproductions dot ca
The problem is not in the cache, as they see it. The problem is that __FILE__ BECOMES opcode, rather than being evaluated at runtime as needed due to hardlinks. They are simply caching the opcode that PHP provides.

This seems reasonable to me as well, except for the fact that __FILE__ becomes unusable if it's cached. It's unreasonable for an opcache to parse the PHP file for use of __FILE__ due to performance reasons, so I'm asking PHP to play nice by providing a feature that will allow the opcache to perform efficiently, while maintaining needed PHP functionality.

Or, alternatively, to clean up the opcodes provided to the caches (xCache, eAccelerator, etc all suffer from this issue) so that __FILE__ isn't evaluated until after the opcode is generated.
 [2008-07-09 15:29 UTC] rpeters at icomproductions dot ca
Since this has not received comment, I take this to mean that the PHP developers do not care that their design choices make it impossible to cache some PHP applications, even though they were designed using recommended features that have no alternatives (like __DIR__).

I would have thought that ensuring there was an efficient way to cache PHP applications, and thereby improve PHP's performance, would have a high priority, and not be considered "bogus". I'm saddened to learn otherwise.
 [2009-08-19 17:23 UTC] rpeters at icomproductions dot ca
So if I want this request re-examined, what do I need to do?
I think the support of opcode caches should be of importance to PHP devs and users alike, and want to ensure this gets a fair examination rather than being dismissed out of hand like it has been so far.
 [2009-08-19 18:05 UTC]
There isn't anything to fix in PHP, if you think we should do something differently then please submit a patch and we'll review it.
 [2009-08-19 21:51 UTC] rpeters at icomproductions dot ca
I don't have the expertise to develop a patch for PHP.

And the issue with PHP is that it's currently impossible for opcode caches to correctly deal with __FILE__ in a hardlinked file.

This is due to the fact that __FILE__ (and __DIR__) is inherently dynamic, but is compiled as a constant. _That's_ PHP's problem.

There are currently no workarounds or any other mechanisms for allowing proper opcode caching. There is no way for a third party to work around this PHP design flaw, only you have the power to change this.

Hence the _feature request_ (not bug report) that one be introduced.

I think it's in everyone's best interest if PHP opcaches are usable in more situations than are currently possible.
 [2011-01-24 23:52 UTC] rpeters at icomproductions dot ca
-Package: Feature/Change Request +Package: *General Issues
 [2011-01-24 23:52 UTC] rpeters at icomproductions dot ca
I am once again asking the PHP devs to implement this feature, or at the very least reconsider flagging this as "Bogus". This is a legitimate feature request with a very significant upside, and marking it as "Bogus" and then telling me to code it myself seems inappropriate.

Either you are against the request, or it should remain as a request that a core developer can implement.
 [2011-04-27 10:41 UTC] simpcl2008 at gmail dot com
The patch of apc_auto_hardlinks_for_php_5.3.5.diff is to add a new key word 
"executed_filename" for PHP 5.3.5 . 

When the following code is running:
echo executed_filename;

In PHP Runtime, zend_get_executed_filename() is called to returned the current 
runtime filename and being displayed.

To fixed the apc hardlinks programs, the apc source code "apc_main.c" should 
also to be modified as follows:

--- APC-3.1.6/apc_main.c	2010-11-30 18:18:31.000000000 +0800
+++ APC-3.1.6-sae/apc_main.c	2011-04-27 15:56:34.000000000 +0800
@@ -559,6 +559,7 @@ static zend_op_array* my_compile_file(ze
             if (h->type != ZEND_HANDLE_FILENAME) {
                 zend_llist_add_element(&CG(open_files), h); 
+            op_array->filename = estrdup(filename);
             return op_array;
         if(APCG(report_autofilter)) {
 [2011-04-27 10:47 UTC] simpcl2008 at gmail dot com
use "executed_filename" to instead of "__FILE__".
 [2012-11-29 05:14 UTC] ashley at netspot dot com dot au
I have to agree with rpeters here - this is a bug because __FILE__ and __DIR__ 
break opcode caches and there isn't a workaround.  In order to work around the 
problem, there needs to be a run-time call available which will return the full 
path to the current file (the equivilent of __FILE__ but at run time).  Same with 

The opcode caches work by hashing the source and assuming that if two source 
files are identical then their opcodes are identical, but unfortunately this is 
not the case because of the magic constants that get replaced during compilation.  
This means that we can't make efficient use of opcode caches if we have multiple 
copies and/or hardlinks of the same file.

From my understanding, this bug is just a request to have a runtime call added so 
we can get the equivilent of __FILE__ and __DIR__ at runtime.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sun Dec 04 02:05:53 2022 UTC