[Fwd: Bug #14798 Updated: session.gc_maxlifetime does not work (Reopen Bug ID #3793)]
| From: | Yasuo Ohgaki | Date: | Sun, 13 Jan 2002 21:24:40 +0000 |
| Subject: | [Fwd: Bug #14798 Updated: session.gc_maxlifetime does not work (Reopen Bug ID #3793)] | ||
| Groups: | php.qa | ||
| Request: | Send a blank email to php-qa+get-4307@lists.php.net to get a copy of this message | ||
Could any windows users confirm this problem?
The reporter is claiming his FAT FS supports mtime, yet session gc
does not work. (When gc is performed, all session data is deleted)
Thank you.
-------- Original Message --------
Subject: Bug #14798 Updated: session.gc_maxlifetime does not work (Reopen Bug ID #3793)
Date: 13 Jan 2002 21:01:20 -0000
From: bs_php@infeer.com (Bs Php)
To: php-dev@lists.php.net
Newsgroups: php.dev
References: <bug-14798@bugs.php.net>
ID: 14798
User updated by: bs_php@infeer.com
Reported By: bs_php@infeer.com
Status: Open
Bug Type: Session related
Operating System: Win 2k
PHP Version: 4.1.0
New Comment:
I'm using FAT32 and mtime is working fine! I use mtime in 2 PHP objects
I've wrote (a cache system and a extention to PHP's session handling)
and mtime is fine!
Again: jmoore@php.net and I suspect the bug in *atime*!!!
NOTE: Fat32 on Win has following effect as described by
hurtado@arrakis.es under the user comment of fileatime()
http://www.php.net/manual/en/function.fileatime.php:
"Windows *does* track file access times, however it seems (that FAT32)
only keep track of the date a file was last accessed, ignoring the
actual time, so if you try to pull the fileatime() for a file in
Windows, you will get 00:00:00. You can verify this by right-clicking
on any file in Windows explorer and viewing the properties of the
file."
If atime is beeing uses then this would explain way all session data is
looked as garbage after 00:24. There must be a fallback *without* the
use of atime because "Some Unix filesystems can be mounted with atime
updates disabled to increase the performance." and because of the Win
FAT32 problem.
Since you are using W2K, could you use NTFS, if not? I can't and don't want to switch to NTFS for several reasons:a) Even if it would work, you can't go and tell ppl to go and change the filesystem! b) I have a dual boot system and depend on the FAT32. Previous Comments: ------------------------------------------------------------------------ [2002-01-11 18:43:50] yohgaki@php.net Clarify: It sounds like problem is in filesystem used. Are you sure your FAT FS supports mtime? i.e. modified time? If you created the partition with old FAT FS. mtime is not supported and it will not work. Since you are using W2K, could you use NTFS, if not? BTW, I don't use W2K now, but files save handler worked for me with PHP 4.0.x. ------------------------------------------------------------------------ [2002-01-08 06:22:40] bs_php@infeer.com
Any windows users can confirm this? What you mean by *any*? At least 3 users working with WIN 2k (Me,kori_mail@hotmail.com, jmoore@php.net) 2 of them using FAT32. (See bug report #3793)
BTW, gc_maxlifetime is in sec. and *explained* explicitly in php.ini IIRC.I read tfm! Read line 2 of my report above: "session.gc_maxlifetime *documented* as a lifetime measured in seconds ... " OK,OK if you say it's secs I'll believe you. I can't verify it because of the current bug. They're indications that the doc could have been wrong (Read my report above) ------------------------------------------------------------------------ [2002-01-06 20:14:03] yohgaki@php.net Any windows users can confirm this? BTW, gc_maxlifetime is in sec. and *explained* explicitly in php.ini IIRC. ------------------------------------------------------------------------ [2002-01-02 08:37:15] bs_php@infeer.com Befor going into the bug-report an importent question: session.gc_maxlifetime documented as a lifetime messured in *seconds* with default = 1440
1440s = 24min. hmm.... 24min ??Expectiong the gc_maxlifetime to be rather long 24 min. seams a short time AND 24 relates more to 24h! So is it realy *seconds* ?!
---The Bug: As reported in Bug ID #3793 (from kori_mail@hotmail.com) following still happens (taken from sniper@php.net, 2000-12-07 and veryfied by mfischer@php.net, 2001-11-25): 1) "session.gc_maxlifetime" does not work - I set this to 60 sec, but I can read values from the session even when time expired. (I start the session and then I wait more than 60 sec before calling other script) 2) When I set "session.gc_probability = 100" in php.ini, ALL other session files are deleted (only one session can be used at the time - if 2 clients are connected to server, the second client deletes session of the first client, etc.). . My Comment: To (1): This may be intended when using cookies! Because if session.cookie_lifetime is =0 (until browser is restarted) finding a valid SID in the cookie may prevent the gc from destroying the session data. (The doc leves this open). To (2): For testing I've set "session.gc_probability = 50" but the effect is the same. As soon as the gc runs, all other session-files are deleted. gc_maxlifetime has no influance. jmoore@php.net wrote that it may have to do with 'atime' and I would think so too. I would consider to use 'mtime' (maybe as fallback). Even the PHP-manual makes restriktions to 'atime': "Some Unix filesystems can be mounted with atime updates disabled to increase the performance." [Session] session.gc_probability = 100 session.gc_maxlifetime = 60 session.save_handler = files session.save_path = c:\tmp\ session.use_cookies = 1 session.name = PHPSESSID session.auto_start = 0 session.cookie_lifetime = 0 session.cookie_path = / session.cookie_domain = session.serialize_handler = php session.referer_check = session.entropy_length = 0 session.entropy_file = ;session.entropy_length = 16 ;session.entropy_file = /dev/urandom session.cache_limiter = nocache session.cache_expire = 180 session.use_trans_sid = 1 ------------------------------------------------------------------------ Edit this bug report at http://bugs.php.net/?id=14798&edit=1 -- Yasuo Ohgaki