|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #46260 __FILE__ should not resolve symlink paths
Submitted: 2008-10-09 01:32 UTC Modified: 2012-04-30 23:04 UTC
Avg. Score:4.6 ± 0.7
Reproduced:109 of 111 (98.2%)
Same Version:54 (49.5%)
Same OS:79 (72.5%)
From: bugs dot php dot net at callum-macdonald dot com Assigned:
Status: Duplicate Package: *General Issues
PHP Version: 5.2.6 OS: Linux
Private report: No CVE-ID: None
 [2008-10-09 01:32 UTC] bugs dot php dot net at callum-macdonald dot com
See these bugs:

The __FILE__ constant should not, in my opinion, resolve symbolic links on *nix operating systems. At the very least, there should be an option to control this behaviour.

Because __FILE__ returns only the symlink resolved path, there is no way to get the symlink path of the currently included file. If __FILE__ returned the symlinkpath, the resolved path could be retrieved with realpath(__FILE__).

The opposite is not true. There is no way to go from the resolved path to the original link path. I realise this is a feature not a bug, but I believe it is a serious shortcoming and limits the ability of PHP in symlinked situations.

Reproduce code:

Expected result:
__FILE__ should return the symlink path

Actual result:
__FILE__ returns the resolved path


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-01-31 22:54 UTC] luke_phpbugs at dashjr dot org
$_SERVER["PHP_SELF"] helps a little.
 [2009-01-31 23:12 UTC] bugs dot php dot net at callum-macdonald dot com
$_SERVER['PHP_SELF'] only relates to the main script, not the currently included file. It's useful, but a completely separate issue.

There is, as far as I can see, no way to get the non symlink resolved path of the currently included file.
 [2009-07-02 16:43 UTC] raphael dot roulet at univ-st-etienne dot fr
If there is no security issue, Why don't PHP make life easier ?
 [2009-09-22 06:42 UTC] glideraerobatics at hotmail dot com
I have the same problem with PHP. I have a slave site that shares most (but not all!) code with a master site using symlinks. The code consists of CLI scripts, web pages, and includes (one of which is a common include for setting up the include_path and error handling). It is critical that this include_path refers to paths in the slave site even though the real common include resides in the master site. I can't achieve this using __FILE__ unfortunately due to the symlink resolution problem. It would be nice to have an alternative to __FILE__, perhaps __LINK__, with unresolved symlinks. Please PHP developers add this!!! PHP needs it so much and it must be a very simple thing to add.

In the mean time, I've created a function in the common include that jumps though hoops in order to set the include_path correctly by using argv[0] in CLI scripts (and traversing up until a htdocs dir is found) or else $_SERVER['DOCUMENT_ROOT'] in web scripts. It's horrible, but the only solution I've found so far.
 [2009-09-26 21:01 UTC] miguel-php at cr dot uz
Another vote for this. The current implementation does not seem like the proper way to treat symlinks, and it makes sharing included files between directories very difficult.

I understand that changing this now has the potential to cause breakage in scripts that depend on the current behaviour. But there really does need to be a way for a file to find its own effective location.
 [2010-08-26 09:12 UTC] rix at mindginative dot com
+1 for this. I encountered this issue today and was hoping that there's a better 
way not to resolve symlink in __FILE__. As suggested above, perhaps __FILE_LINK__ 
that either return the symlink path or false if none.
 [2010-11-10 16:52 UTC] jimmy at powerzone dot dk
I agree. Hosting multiple PHP systems based on the same installation is no easy task, when __FILE__ is used in conjunction with symlinks. Very frustrating. I vote for a new contant; __FILEPATH__ which does not resolve symlinks.
 [2010-12-10 18:12 UTC] php at micropro dot cz
I think I have a resoulution ... use $_SERVER["SCRIPT_FILENAME"] instead of __file__. It should work the same way, but is absolute path, not resolved. It works for me fine :-)
 [2011-04-27 04:38 UTC] gnoodl+php at gmail dot com
$_SERVER["SCRIPT_FILENAME"] cannot be used in place of __FILE__ as it does not 
resolve the path of an included file.


// file1.php
include 'file2.php';

// file2.php

Executing file1.php will result in "/path/to/file1.php"
 [2011-07-26 16:54 UTC] tony at brown dot org
I'm another +1 for this, causing me some real headaches because for deployment I store multiple versions of a site with the latest been symlinked to for apache.

There are modules in the application which are licensed and use the file path as part of it's verification. When we deploy, the path is seen as changed and the modules get disabled. :-(
 [2011-10-25 19:45 UTC] nars at clix dot pt
 [2011-12-22 13:45 UTC] monsen dot dag at gmail dot com
If you're on an enviroment with bash available, you can use this snippet to get 
__FILE__ without resolving symlinks.

It's a small hack, but it should be pretty safe.

$output = array();
exec('pwd', &$output);
define('__LINK__', $output[0].substr(__FILE__, strpos(__FILE__, 
 [2011-12-26 15:51 UTC] bugs dot php dot net at callum-macdonald dot com
I tested monsen.dag's suggestion and it produced a completely different result than expected. Also, defining a constant will only apply once, not to the *currently executing file*, which is the great advantage of __FILE__. This suggestion does not provide a solution of any kind as far as I can tell.
 [2011-12-28 13:40 UTC] contato at mesotec dot com dot br
+1 too. I really need this feature.

In windows 7 realpath for a file that is accessed through a mklink folder does return the link path not the absolute one.
 [2012-04-23 09:16 UTC] sdbondi at gmail dot com
So nothing is being done about this issue?

It seems to have been an issue for at least 6 years without
a adequate solution. 

The behaviour of the __FILE__ constant seems in violation 
of convention and what developers would expect from it.
This bug (yes, bug) prevents us from keeping code (like 
wordpress and a theme) in their own repositories in e.g.
Git (cannot checkout sub-folders - git submodules would 
only work if you didn't want to keep theme build, 
documentation etc. files versioned in the repo). 

I really don't get why this behaviour is not at least configurable.

What is the use case of resolving symlinks? 
I suspect no one would be able to find a use that couldn't
be done in a better way.
 [2012-04-30 22:23 UTC] alex at wordnik dot com
After 4 years of bug report, this issue still remains.  Unbelievable.  It's such 
a small change to make the behaviors more consistent (and correct), and helps 
simplify developer's life.

No flamebait here, but no wonder PHP is like a dead language, with most people 
move on to other languages, Python, Ruby, to name a few, while those who are 
stuck with PHP for Wordpress and other sites, suffer.
 [2012-04-30 23:04 UTC]
@alex at wordnik dot com

It is required as part of the require/include_once function. Sources file paths 
are always resolved. It is not a bug but a design choice, which allows many 

That being said, anyone using symbolic links in prod across different sites 
should reconsider this choice as well.

Let close this bug and mark as duplicated.
 [2012-04-30 23:04 UTC]
-Status: Open +Status: Duplicate -Package: Feature/Change Request +Package: *General Issues -Block user comment: No +Block user comment: Yes
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Apr 22 07:01:29 2024 UTC