Description:
------------
When open_basedir is set to /home/user, and /home/user is symlinked to /home2/user, then actions like creating files containing the path "/home/user" fail.
All symlinks within the open_basedir value are getting resolved to their real locations, meaning that a setting of "/home/user:/home2/user" gets resolved to "/home2/user:/home2/user" (as documented).
What users would expect is that symlinks are also resolved in the destination filenames of file-manipulating actions. Currently this isn't being done, leading to open_basedir restriction errors.
This behaviour has already been reported as #32851, #31309 and #30188, mostly with a solution of providing a link to the latest CVS snapshots or with no result. php4-STABLE-200509291243 and php5-STABLE-200509291239 both still have this problem.
If this a feature, it should be documented in another way, mentioning that the symlink-resolving is only done on one side and that using symlinks in open_basedir does not work for creating files without providing the "real" (non-symlinked) filename/path. If it isn't, this is most likely a bug and should be solved.

Reproduce code:
---------------
symlink /home/test -> /home2/test

open_basedir /home/test:/home2/test

<?php fopen("/home/test/foobar","w"); ?>


Expected result:
----------------
No errors? :)

Actual result:
--------------
Warning: fopen(): open_basedir restriction in effect. File(/home/test/foobar) is not within the allowed path(s): (/home/test:/home2/test)