When running php-4.2.3 as a nsapi module under iplanet webserver 6.0SP4  I have noticed the following behaviour:
When attempting to delete a symbolic link to a file, the file get's deleted instead of the intended deletion of the symbolic link.

Test script:

<?php

$orgdir="/tmp/phptest-org/";
$goaldir="/tmp/phptest-goal/";

echo "Making test dirs";
mkdir($orgdir,0777);
mkdir($goaldir,0777);

// make test files in orgdir
for ($i=0; $i<5; $i++) {
        $testname="testfile_" . $i;
        $fp=fopen($orgdir . $testname,"w");
        fwrite($fp,"this file contains nothing\n");
        fclose($fp);
}
sleep( 5);
// now create the symlinks in the goaldir
for ($i=0; $i<5; $i++) {
        $testname="testfile_" . $i;
        $target="../phptest-org/" . $testname;
        $link=$goaldir . "$testname";

        symlink($target,$link);
}

// now delete the symlinks in the goaldir
for ($i=0; $i<5; $i++) {
        $testname="testfile_" . $i;
        $link=$goaldir . "$testname";
        unlink($link);
}

?>


My configure line:
./configure  --prefix=/opt/iplanet/servers/plugins --with-nsapi=/opt/iplanet/servers --enable-sysvsem --enable-sysvshm --with-mysql=no --enable-bcmath --with-cli

Running php as module in Iplanet Webserver 6.0 SP4 on Solaris 9 Generic

From the manpage:
System Calls                                            unlink(2)

NAME
     unlink, unlinkat - remove directory entry

SYNOPSIS
     #include <unistd.h>

     int unlink(const char *path);

     int unlinkat(int dirfd, const char *path, int flag);

DESCRIPTION
     The unlink() function removes a link  to  a  file.  If  path
     names  a  symbolic  link, unlink() removes the symbolic link
     named by path and does not  affect  any  file  or  directory
     named by the contents of the symbolic link.
      Otherwise, unlink() removes the link named by the  pathname
     pointed to by path and decrements the link count of the file
     referenced by the link.
<snip>


looking at the source code in TSRM/tsrm_virtual_cwd.c.
the following code snipper caught my eye:

CWD_API int virtual_unlink(const char *path TSRMLS_DC)
{
 	cwd_state new_state;
	int retval;

	CWD_STATE_COPY(&new_state, &CWDG(cwd));
>>    virtual_file_ex(&new_state, path, NULL); <<

	retval = unlink(new_state.cwd);

	CWD_STATE_FREE(&new_state);
	return retval;
}

In virtual_file_ex the following happens:
CWD_API int virtual_file_ex(cwd_state *state, const char *path, verify_path_func verify_path)
{
 	int path_length = strlen(path);
	char *ptr, *path_copy;
	char *tok = NULL;
	int ptr_length;
	cwd_state *old_state;
	int ret = 0;
	int copy_amount = -1;
	char *free_path;
	unsigned char is_absolute = 0;
#ifndef TSRM_WIN32
	char resolved_path[MAXPATHLEN];
#endif

      	if (path_length == 0)
		return (0);

#if !defined(TSRM_WIN32) && !defined(__BEOS__)
	if (IS_ABSOLUTE_PATH(path, path_length)) {
		if (realpath(path, resolved_path)) {
			path = resolved_path;
			path_length = strlen(path);
		}

When looking at the manpage for realpath:
Standard C Library Functions                         realpath(3C)

NAME
     realpath - resolve pathname

SYNOPSIS
     #include <stdlib.h>

     char *realpath(const char *file_name, char *resolved_name);

DESCRIPTION
     The realpath() function derives, from the  pathname  pointed
     to  by  file_name,  an absolute pathname that names the same
     file, whose resolution does not involve ".", "..",  or  sym-
     bolic  links.  The generated pathname, using PATH_MAX bytes,
     is stored in the buffer pointed to by resolved_name.
<snip>

The crux here is the resolution of realpath combined with the use of symbolic links. When using php_unlink($targetfile), $targetfile gets resolved into the _real_ file, not the symlink and thus the wrong directory entry gets deleted. My goal is to use symbolic links to provide exactly this from happening.

As a fix I suggest either adding a function rmlink()  (in parallel to symlink() and link() ) that needs to be used to delete links or updating the virtual_unlink code to check for the correct directory entry and not the correct file.