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.

Please use the developers mailinglist for feature discussions (internals@lists.php.net).

Moved to Feature/Change request category.

Fixed subject.

$_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

@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.

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__).

I don't know why this was assigned to me

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

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).

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.

I agree that this isn't a bug. I filed it as a change/feature request. Please revert.

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.

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.

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.

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.