Bug #14798 Updated: session.gc_maxlifetime does not work (Reopen Bug ID #3793)

From: Date: Mon, 14 Jan 2002 01:30:28 +0000
Subject: Bug #14798 Updated: session.gc_maxlifetime does not work (Reopen Bug ID #3793)
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-76953@lists.php.net to get a copy of this message
ID: 14798
Updated by: yohgaki
Reported By: bs_php@infeer.com
Old Status: Open
Status: Analyzed
Bug Type: Session related
Operating System: Win 2k
Old PHP Version: 4.1.0
PHP Version: 4.1.1
New Comment:

Under Windows, session save path's directory is FAT FS and save handler
is files, gc call is deleting all session files. 

Status = Analyzed.

(I cannot fix this one, since it's windows specific :)


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

[2002-01-13 17:03:06] bs_php@infeer.com

OK, as I thought: The test (see top entry) works on Win with NTFS.
What I did:
 a) I set session.gc_probability = 100
 b) I mad a little FAT32 partition on F: and a NTFS partition G:

The bug *only appears* when using FAT32: 
   session.save_path = F:\tmp

Session works fine when using NTFS:
   session.save_path = G:\tmp

So it MUST be a *atime* related problem. 

------------------------------------------------------------------------

[2002-01-13 16:22:13] yohgaki@php.net

Ok, I'll assume your FAT FS supports mtime.
However, I still have to ask you if it work with NTFS. I don't use
Windows now .

If there is a problem, I think problem is in TSRM code ;)

------------------------------------------------------------------------

[2002-01-13 16:01:19] bs_php@infeer.com

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.


------------------------------------------------------------------------

[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)


------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/?id=14798


Edit this bug report at http://bugs.php.net/?id=14798&edit=1



Thread (15 messages)

« previous php.dev (#76953) next »