There was an omission in the original report. The problem with session_destroy() was exposed because I had included some code in my session logic that correctly set the session cookie with the path session_start() should set but does not (see bug #4920).

My logout function is now:

session_destroy();

// Manually expire things since session_destroy doesn't.
$CookieParms = session_get_cookie_params();
setcookie(session_name(), '', time(), $CookieParms["path"], $CookieParms["domain"]);
setcookie(session_name(), '', time(), '/members/', $CookieParms["domain"]);

This works in that the browser will stop using that session ID and will thus be assigned a new one by the next session start.

However, the big problem here is that session_destroy() doesn't actually destroy anything, contrary to the documentation. If the browser continues to ask for a given session identifier, all of that data will still be available. I can't even delete the temp file as unlink() is broken on Win32!

There was an omission in the original report. The problem with session_destroy() was exposed because I had included some code in my session logic that correctly set the session cookie with the path session_start() should set but does not (see bug #4920).

My logout function is now:

session_destroy();

// Manually expire things since session_destroy doesn't.
$CookieParms = session_get_cookie_params();
setcookie(session_name(), '', time(), $CookieParms["path"], $CookieParms["domain"]);
setcookie(session_name(), '', time(), '/members/', $CookieParms["domain"]);

This works in that the browser will stop using that session ID and will thus be assigned a new one by the next session start.

However, the big problem here is that session_destroy() doesn't actually destroy anything, contrary to the documentation. If the browser continues to ask for a given session identifier, all of that data will still be available. I can't even delete the temp file as unlink() is broken on Win32!

session_destroy destroys session data, not session itself.
That's what manual says.
Also, session_destoy is void, so how would you expect it to return anything?

<BLOCKQUOTE>session_destroy destroys session data, not session itself.
That's what manual says.</BLOCKQUOTE>

When you use the built in files handler, the data is not destroyed. Future requests with the same session ID (e.g. for some reason the cookie isn't deleted or you have the session ID embedded in a URL) will still have all of the old session data. There's no way this counts as deleting the data.

OK, then we need reproducing script and your session variables settings in php.ini
I just tried it and for me it works.

PHP.ini:
session.save_handler = files
session.save_path = D:\TEMP\PHPSessions

<?
	session_start();
	session_register('counter');

	echo "<P>Reload count: " . @$counter++ . "</P>";

	if ($counter < 10) {
		echo '<A HREF="bug_5231.php?PHPSESSID=' . session_id() . '">Reload</A>';
	} else {
		echo "Hit reload limit. Destroying session";
		session_destroy();
	}
?>

Observed behaviour is that the session count will be reach nine and stay there. session_destroy() will be called each time at that point, which appears to prevent counter's change to 10 from being written. However, the session still remains valid and so "Reload count: 9" will be displayed for all subsequent reloads. A working session handler will restart at zero after the session is destroyed.

Well, it works for me again. Please try 4.0.1pl2 - maybe it will work for you too.

definetly works for unix, maybe it's a windows problem?


by the way, since July 4th session_destroy() 
will return success status as true or false

No feedback from user.

--Jani

Re-opened because it was closed in error. The problem still happens, there's a script which reproduces the problem on the listed platform and it's still a bug in all released versions of PHP4 including 4.0.1pl2, as was mentioned in response to both previous questions.

Have you tried latest CVS or snapshot from snaps.php.net?

--Jani

Again, NO feedback for a while..please try php4.0.2 and if that 
doesn't work, the latest CVS or snapshot. Reopen if problem still exists.

--Jani

reopened due to new bug reports and I verifed that this does not work on *win32*, this message appears:

Warning: Session object destruction failed in ...

duped out about 7 similar bugs, this *is* a win32 issue and should be fixed before 4.0.3

fixed in cvs already, wait for 4.0.4