php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #42516 __FILE__ resolves symlinks
Submitted: 2007-09-01 21:02 UTC Modified: 2013-01-23 19:01 UTC
Votes:24
Avg. Score:4.9 ± 0.3
Reproduced:24 of 24 (100.0%)
Same Version:8 (33.3%)
Same OS:20 (83.3%)
From: michael at zedeler dot dk Assigned:
Status: Not a bug Package: Scripting Engine problem
PHP Version: 4.4.7 OS: Linux
Private report: No CVE-ID: None
 [2007-09-01 21:02 UTC] michael at zedeler dot dk
Description:
------------
__FILE__ does not return the path used to invoke the current file, but resolves symlinks.

This behaviour is extremely problematics, since important information is thrown away. The web is teeming with postings from people that are experiencing problems because of this.

In http://bugs.php.net/bug.php?id=37603 this bug was mentioned and the response was that it is intended behavior with a reference to the manual.

The page

http://es.php.net/manual/en/language.constants.predefined.php

is the primary source of information for __FILE__, and it does not mention resolving symlinks at all.

I'd like if we could have som kind of dialogue about how to solve the problem, in stead of just having this bug being closed with a "Bogus" status.

My suggestions are:

 1) introduce a new magical constant that behaves as it should.
 2) put a parameter in php.ini that changes how __FILE__ behaves.


Reproduce code:
---------------
This is basically a reopening of http://bugs.php.net/bug.php?id=37603

Expected result:
----------------
This is basically a reopening of http://bugs.php.net/bug.php?id=37603

Actual result:
--------------
This is basically a reopening of http://bugs.php.net/bug.php?id=37603

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-04-23 17:53 UTC] michael at zedeler dot dk
Sorry to bug you again, but as I am writing in the report, just putting a description of the errant behaviour is not a useful fix.
 [2009-04-24 05:58 UTC] bjori@php.net
Please use the developers mailinglist for feature discussions (internals@lists.php.net).
 [2009-08-17 12:56 UTC] michael at zedeler dot dk
Moved to Feature/Change request category.
 [2009-08-17 12:57 UTC] michael at zedeler dot dk
Fixed subject.
 [2011-04-08 18:10 UTC] jani@php.net
-Package: Feature/Change Request +Package: Scripting Engine problem
 [2011-04-13 09:32 UTC] tyra3l at gmail dot com
$_SERVER["SCRIPT_FILENAME"] can be used for getting the non-resolved path, and the 
documentation at 
http://php.net/manual/en/language.constants.predefined.php
now contains info about __FILE__ is resolved to absolute path with resolved 
symlinks.
so I think that this could be closed.

Tyrael
 [2011-07-20 05:23 UTC] mpok at xs4all dot nl
@Tyra3l: the problem most people (including myself) are having is that 
$_SERVER["SCRIPT_FILENAME"] contains the path to the file that was called, not 
the path to the file that is actually processed. This means you can't use 
$_SERVER["SCRIPT_FILENAME"] as a replacement for __FILE__; in fact there is no 
way to get a non-resolved path to the current script.

Example:
Website calls [DOCUMENT_ROOT]/index.php
Cronjob calls [DOCUMENT_ROOT]/lib/cron/maintenance.php

Both files include [DOCUMENT_ROOT]/lib/config/startup.php

Now the startup.php script has to set path variables/constants to use throughout 
the framework. If you use __FILE__ for this it will return the path to the 
settings.php script, regardless of whether it was included/called from the 
website (index.php) or the cronjob (maintenance.php). This allows you to 
reliably set paths relative to the location of settings.php.

However if you symlink the /lib/ directory __FILE__ will resolve the symlinked 
path and thus break for setting the framework paths relative to the website.

Using $_SERVER["SCRIPT_FILENAME"] in startup.php will result in different paths 
depending on which file was called. When called from the website it returns "
[DOCUMENT_ROOT]/index.php", when called from the cronjob it returns "
[DOCUMENT_ROOT]/lib/cron/maintenance.php". This means that if you want to make 
sure you get a reliable path to the lib inside the website you'd have to write a 
bunch of additional code with semi-intelligent matching in order to find a 
specific path, if at all possible. Another option is to set the base path 
seperately in each file that is an entry point for the framework so that those 
files define their existence relative to the lib dir. This does create more 
dependencies though.

All in all it would be far better if there was an option in the php.ini to 
disable symlink resolving for __FILE__ (and subsequently __DIR__). If I want to 
resolve symlinks I'd use realpath() anyway.
 [2011-08-20 09:56 UTC] clicky at erebot dot net
Also, the DOCUMENT_ROOT workaround only works in case you're dealing with a website. It's completely useless in case you're working from a terminal (eg. some unit tests run through PHPUnit).

+1 on having this behaviour changed (maybe as a second magic constant as other proposed, so as not to break backward compatibility for __FILE__).
 [2012-04-06 17:28 UTC] bjori@php.net
I don't know why this was assigned to me
 [2012-04-06 17:28 UTC] bjori@php.net
-Status: Assigned +Status: Open
 [2012-04-06 17:29 UTC] bjori@php.net
-Status: Assigned +Status: Open -Assigned To: bjori +Assigned To:
 [2012-06-15 07:43 UTC] daniele dot segato at gmail dot com
This bug was open since 2007

would you mind assigning it to someone for fixing or discuss why you are leaving 
it open?
maybe someone out there can help you

thank you
 [2013-01-23 17:36 UTC] ale dot comp_06 at xox dot ch
On development server I often have symlinked directories to common libraries.

It would be wonderful to have an option for the behavior of __FILE__ and allow it to return the non resolved path if the developer wishes so.

Generally speaking, having some paths automatically "resolved" and some not, is very disturbing. As far I can tell, all paths should be unresolved and one should use "resolve_path()" to get the "real" path. A central switch should allow to get all the paths resolved if one wants so (or the other way: the default being the paths being resolved and the switch makes them unresolved).
 [2013-01-23 19:01 UTC] pajoye@php.net
-Status: Open +Status: Not a bug
 [2013-01-23 19:01 UTC] pajoye@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

It is required by require_once and include_once, along other things (realpath 
cache). It always been like that.
 [2013-01-24 15:21 UTC] michael at zedeler dot dk
I agree that this isn't a bug. I filed it as a change/feature request. Please revert.
 [2018-12-03 00:47 UTC] pmugane at gmail dot com
Really concerned about how this whole process has been ignored.

If __FILE__ is intended to resolve symlinks by design then provide a way to get the directory of the symlink - it's really not that hard. 

Seriously, it's been over a decade and this is still unresolved.
 [2021-05-26 11:55 UTC] zjz at zjz dot name
Here's a scenario where symlinks-unresolved path constants are helpful:

Suppose there are two sub-projects d1 and d2, and I want to reuse some file of d1 in d2, then I apply soft link to it:

/<path-of-d1>/f1.php
/<path-of-d1>/f2.php
/<path-of-d2>/f1.php --> /<path-of-d1>/f1.php (soft link)
/<path-of-d2>/f2.php

The content of /<path-of-d1>/f1.php contains the following the include directive:

include __DIR__ . '/f2.php';

The included path is always resolved as /<path-of-d1>/f2.php, it would be unfortunate if in fact we want the /<path-of-d2>/f2.php to be included. I think introducing a new pair magical constants corresponding to __FILE__ and __DIR__ is desirable.

Thank you.
 [2024-01-05 06:56 UTC] gerardreches at gmail dot com
I am using WordPress and instead of copying my plugins files for each WordPress installation, I am using them through symlinks.

Some of these plugins require the unresolved path for WordPress to be able to enqueue styles and scripts. These plugins may either be used as a plugin or a library as part of another plugin, which makes alternatives to retrieve the path unusable.

17 years, multiple requests, and nothing has been done yet about this. We are not even asking for the __FILE__ and __DIR__ behaviour to be changed, but to get a new pair of constants that return the unresolved path.
 [2024-01-07 18:02 UTC] michael at zedeler dot dk
Every time I am asked if I can take on PHP assignments, I remember this ticket and turn them down. I could elaborate, but then I would probably be in violation of the community guidelines.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Oct 11 21:01:27 2024 UTC