ID: 14798
Updated by: yohgaki
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Session related
Operating System: Win 2k
PHP Version: 4.1.0
New Comment:

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. 


Previous Comments:
------------------------------------------------------------------------

[2002-01-08 06:22:40] [EMAIL PROTECTED]

> Any windows users can confirm this?
What you mean by *any*? At least 3 users working with WIN 2k (Me,
[EMAIL PROTECTED], [EMAIL PROTECTED]) 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] [EMAIL PROTECTED]

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] [EMAIL PROTECTED]

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 [EMAIL PROTECTED]) following
still happens (taken from [EMAIL PROTECTED], 2000-12-07 and veryfied by
[EMAIL PROTECTED], 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. 

[EMAIL PROTECTED] 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


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to