ID: 45421 User updated by: rpeters at icomproductions dot ca Reported By: rpeters at icomproductions dot ca Status: Bogus Bug Type: Feature/Change Request Operating System: CentOS 4.3 PHP Version: 5.2.6 New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [2008-07-02 22:56:50] [EMAIL PROTECTED] 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 22:08:28] 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:00:29] [EMAIL PROTECTED] 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 21:54:35] rpeters at icomproductions dot ca Related to APC Bug# 14055 http://pecl.php.net/bugs/bug.php?id=14055 ------------------------------------------------------------------------ [2008-07-02 21:53:23] rpeters at icomproductions dot ca Description: ------------ 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: --------------- CURRENTLY: /1/test.php: <?php require(__DIR__ . '/testDest.php'); ?> /2/test.php created by "cp -l ../1/test.php" /1/testDest.php: <?php echo 1; ?> /2/testDest.php: <?php echo 2; ?> PROPOSED: /1/test.php: <?php require($_SERVER['PHP_DIR'] . '/testDest.php'); ?> /2/test.php created by "cp -l ../1/test.php" /1/testDest.php: <?php echo 1; ?> /2/testDest.php: <?php echo 2; ?> Expected result: ---------------- /1/test.php displays "1", and /2/test.php displays "2" Actual result: -------------- CURRENTLY: When running APC, both scripts will return the results of whichever one you hit first. PROPOSED: When running APC, /1/test.php displays "1", and /2/test.php displays "2" ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=45421&edit=1
