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

go to bug id or search bugs for

Bug #38790 __FILE__ resolves symlinks?
Submitted: 2006-09-12 14:20 UTC Modified: 2006-09-12 22:02 UTC
From: php dot net at yereth dot nl Assigned:
Status: Not a bug Package: Filesystem function related
PHP Version: 4.4.4 OS: SUSE 9.2
Private report: No CVE-ID: None
View Developer Edit
 [2006-09-12 14:20 UTC] php dot net at yereth dot nl 
Description:
------------
__FILE__ resolves symlinks in 4.x.

This is very undesirable. If this was intentionally, perhaps another magic constant can be introduced that does not resolve the symlink. Besides that, I can always use realpath(__FILE__), which is another reason why __FILE__ shouldn't resolve; resolving is easy, the other way around is impossible without further contextual information.

Rephrasing the problem: if __FILE__ doesn't give me the name of the symlinked file, there is nothing that does, as far as I know. This restricts me terribly in my possibilities and forces developers to redundancy, as symlinks do not give the desired result, obviously.

Hopefully you'll see that an addition to the magic constants or a change in function of __FILE__ enhances the possibilities of developers.

Thanks in advance!

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-09-12 16:44 UTC] tony2001@php.net 
Yes, this is expected behaviour.
 [2006-09-12 22:02 UTC] php dot net at yereth dot nl 
Wow.. that's an extremely useful comment.. thanks! I'm very glad that you just ignore the most important part and that you don't wish to improve the PHP engine.

There is also a difference (but correct me if you're a native speaker in English) between 'expected' and 'desirable'... maybe you could re-read my previous comment keeping that in mind. You may just improve the language! Good luck!

</sarcasm_mode>
 
PHP Copyright © 2001-2026 The PHP Group
All rights reserved. 		Last updated: Fri Jan 02 18:00:01 2026 UTC