[Hardy][Regression] PHP 5.2.4 symlink bug breaks TYPO3 default setup

Thanks for the bug report, I was able to confirm this and looking at backporting this patch.

Thanks
chuck

Thanks for the bug report however I am marking this as wontfix because it is the desired behaviour now.

http://ca3.php.net/manual/en/function.realpath.php#82770

Thanks
chuck

I am not sure if this really has to do with pathinfo.

But i'm really sure that this is not desired behaviour.
This was fixed in PHP 5.2.5, check out PHP's bug tracker ( http://bugs.php.net/bug.php?id=42587 ):
> [10 Sep 2007 10:56am UTC] <email address hidden>
> This bug has been fixed in CVS.

Or the changelog ( http://www.php.net/ChangeLog-5.php ):
> Version 5.2.5
> 08-November-2007
> [...]
> Fixed #42587 (behavior change regarding symlinked .php files). (Dmitry)

Not pathinfo, I meant realpath.

From the TYPO3 bugtracker ( http://bugs.typo3.org/view.php?id=6158 ):
> Debian/Testing has now "PHP 5.2.5-2" which doesn't have the PHP bug anymore.

I think http://ca3.php.net/manual/en/function.realpath.php#82770 is a different thing.
TYPO3 doesn't check for the existence of files with realpath(), the problem is that PHP 5.2.4 sets a different (from every earlier and later version) current working directory when the script is a symlink.

Can someone please fix this bug? As Jakob pointed out, this is NOT the intended behavior of PHP, hence why the upstream developers have fixed this regression in 5.2.5. It doesn't make sense to leave this broken in this (and only this) release of Ubuntu, especially for an LTS server release.

This affects other functions and variables as well, such as $_SERVER['SCRIPT_FILENAME'] referring to the symlink target rather than the link itself.

Nitro322:

Since this behaviour is what upstream provided in PHP 5.2.4, changing that in an LTS release is probably not all that safe (who knows how many PHP applications running on existing 8.04 LTS servers might depend on it?). Whether upstream *intended* that behaviour or not is not really the issue at this late date. It is what they provided.

However, it would be reasonable, IMO, to get a newer release of PHP into hardy-backports, so that those who consciously *decide* to use -backports (and so decide to deal with any issues resulting from such upgraded versions of software on their server(s)) can easily use a newer version of PHP which does not have this particular behaviour.

Please see https://help.ubuntu.com/community/UbuntuBackports for more info, especially the "How to Request new Packages", "How to Help" and "Backport Process" sections.

Are you willing and able to backport, or at least to help backport, a new version of PHP to Hardy in this way?

I think adding the fix to a package in backports is a good compromise. I wouldn't even suggest necessarily upgrading PHP to a newer version, just fixing this obvious bug. I don't disagree with your concern that changing this behavior now may affect people that have already had to work around it, but conversely I think it's important that it be fixed specifically because this is an LTS release. People running this release may not otherwise be able to upgrade to a fixed version for at least 2 years.

I'd certainly be happy to help out with the backport in some way, especially regarding testing, but I'm not very familiar with deb packaging.

I respons to comment #6.

This behaviour exists in only one release of php5, it's not in any way the intended way of php. By just reading the bug report and looking at the fast response by the developers it stands clear that this is not the intended behavior of php5.2.n

But with your explenation, Jonathan Marsden, I hope this 'feature' remains in 10.04. Ubuntu promises seamless upgrade between LTS releases so the bug must then remain forever....