php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #27711 implicit garbage collector for sessions in PHP
Submitted: 2004-03-26 05:27 UTC Modified: 2004-04-12 17:56 UTC
From: mazsolt at yahoo dot com Assigned:
Status: No Feedback Package: Session related
PHP Version: 4.3.4 OS: win32 + iis 6.0
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mazsolt at yahoo dot com
New email:
PHP Version: OS:

 

 [2004-03-26 05:27 UTC] mazsolt at yahoo dot com
Description:
------------
this post seems to the "Bug #12888 garbage collector" post. I had the same problems, but I tested your advices, too.

I made a script which handles the session's operations. One of them was the session's garbage collector. the implicit gc has the probability to start = 1/100 
In my customized session-handler I changed this value to 100/100. the script works, it deletes the old datas every time. 

If I handle sessions with the implicit garbage collector from PHP, it doesn't want to delete anything. 
I changed the configuration file setting to: 
-- 
session.gc_probability 100 
session.gc_divisor 100 
-- 
if I start a script which calls session_start(), it won't delete the old session datas (from a week ago...) 

It wants to work.it's a windows problem???
there is my script here:

Reproduce code:
---------------
<?
ini_set("session.gc_probability",100);
ini_set("session.gc_divisor",100);
ini_set("session.gc_maxlifetime",10); 
session_start();
?>


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-03-29 16:38 UTC] edink@php.net
What file system is your temp directory on (ntfs, or fat32)?
 [2004-03-30 02:51 UTC] mazsolt at yahoo dot com
operating system: windows 2003 (ntfs). 
I've read in the documentation, that older filesystems cannot keep track the modify time, and the garbage collector is checking the modify time, not the last access time. 

all three functions: 
 - filectime()
 - fileatime()
 - filemtime()
 seems to work correctly.

I believe that the problem is elsewhere. Couldn't it be , that GC simply doesn't work on windows' systems???
I repeat, when I wrote my own session_handler, the gc was executed after the open & read functions, but before the write & close functions. I tested this very easy, putting an echo "function_name" in each of them. but the implicit gc doesn't move anything....
 [2004-04-07 08:58 UTC] sniper@php.net
Are you sure the file permissions / owners are the same..?
(this worked fine with latest CVS in Linux, WHEN I ran the script as root :) So try the latest STABLE snapshot too.


 [2004-04-07 09:22 UTC] mazsolt at yahoo dot com
all the session files are placed in the ./tmp directory, which is a folder all of the current virtual directories.
the owner is IUSER_pcname for all. it has all rights, except change rights. I don't think this affects the gc
 [2004-04-07 10:56 UTC] sniper@php.net
Everything and anything can affect it when speaking of windows..so make it have ALL rights on the files..

 [2004-04-12 17:56 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2013-08-20 16:20 UTC] daverandom@php.net
Automatic comment from SVN on behalf of daverandom
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=331179
Log: Added the note about passing 0 as base to intval() to autodetect the base for conversion.

--
Provided by anonymous #27711 (d.chekaliuk@invisilabs.com)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 09:01:28 2024 UTC