Does this work:

$f = fopen("/export2/home/websites/it/test", "w");

ie. writing to the actual directory..?

$f = fopen("/export2/home/websites/it/test", "w");

does work.

To perhaps clarify - after the file was created with your code:

$f = fopen("/export2/home/websites/it/test", "w");

the previously unsuccessful attempt:

$f = fopen("/export/home/websites/it/test", "w");

does work (as I mentioned in the initial report).
So just the file's creation fails in combination with the symlink.

This is expected behaviour and it's documented in the docs:
"When a script tries to open a file with, for example, fopen() or gzopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to open it. All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink."
http://www.php.net/manual/en/features.safe-mode.php
Pay attentions to the last sentence.

I've read the documentation. At the risk of repeating myself:

If the symlink was resolved - I would expect at least one of the given open_basedirs to match (as both possibilities are specified - resolved and unresolved).

If this is not the intended way it should work, why is there a difference between creating a new and opening an existing file (as opening an existing file in the symlinked directory works, while creating a new file fails)?

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I suppose the problem lies with the fact that symlinks in open_basedir are getting resolved, while symlinks in fopen-calls aren't.
For example, we have open_basedir /home/bla:/home2/bla and symlink /home/bla -> /home2/bla.
The following fopen calls fails:
fopen("/home/bla/foobar","w");
since the open_basedir virtually gets resolved to /home2/bla:/home2/bla (as documented in the php docs). What is not documented and I still think is a bug (even after reading #32851, #31309 and some not very friendly comment by tony2001 in #30188) is the fact that the symlink within the directory of the destination path is not getting resolved.
One can not use any path within "/home/bla" for file creating (or upload moving) as the open_basedir values have their symlinks resolved while the destination files haven't.
We solved it by symlinking a subdirectory of /home/bla to /home2/bla and using that one, as this solution doesn't use a symlinked path in the open_basedir setting which would get resolved.
I still think it should be possible to set an open_basedir restriction to a symlink without running into the above-mentioned problem, e.g. by also resolving the symlink in the destination filenames.
This has been verified with php4-STABLE-200509291243 and by looking at the source of php5-STABLE-200509291239.

I was very impressed about opportunity to work from home and I register to website work-home.org now i have  lots of  offers to work from home..  I am very thankful my friend who told me about this website. I quit my job and I am working  from home only. I am very happy  being of my family together all the time ;) Did you hear something about that? Maybe You know something about that too?