Re: Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work

That could work. Would require an extra callback for the custom session code. Basically a 'touch' callback would need to be added. But I suppose that would need to be added regardless to support readonly mode. -R On Sat, 17 Aug 2002, Zeev Suraski wrote: > Coming to think of it, how about: > > (a) Always use mtime > (b) 'touch' the file in case of session-readonly > > That would allow users to have the performance benefit of noatime for all > of the files on the filesystem, except for the session files. 'touch'ing > the file should take about the same time as accessing it on an > atime-enabled filesystem, I think. This would give us the best of both worlds. > > Zeev > > At 13:39 17/08/2002, Zeev Suraski wrote: > >Ok, that makes sense. I like the idea of being able to configure whether > >you want to use mtime or atime, so that non atime-compliant filesystems > >can still be supported, but we leave the window to support > >session-readonly in the future. > > > >Zeev > > > >At 07:37 17/08/2002, Rasmus Lerdorf wrote: > >>Ok, thinking a bit more about this.. session_readonly() really should be > >>implemented. Imagine a system where you have dynamically generated > >>images/flash/pdf or even just a straight framed site. You use sessions to > >>pass information around between not only pages, but also to the > >>dynamically generated pieces of a page. Having the session backend > >>rewrite the same session data many times per request is a waste and if you > >>know that you are only going to read in the pdf generator script, for > >>example, it would be a good idea to open the session readonly from that > >>script. Or not even that fancy. You have a standard login page where you > >>pull some data from a database about the user, stick it in a session and > >>then the user clicks through the rest of the site. It wouldn't be that > >>strange to have hundreds of pages that would need to read that session > >>data, but never write to it. With the current implementation we are > >>needlessly overwriting the same data on every single request. > >> > >>If session_readonly() gets implemented then removing atime support for > >>filesystems that support that seems like a step in the wrong direction. > >>We should perhaps have a modifier on session mod_files which tells it > >>whether it should use atime, mtime or perhaps even ctime. Another > >>configuration directive sucks, but even if we could detect at runtime that > >>atime was not supported, silently falling back to mtime doesn't seem like > >>a good idea. I suppose we could change the default to mtime, implement > >>session_readonly() and give people the option to switch it to atime. > >> > >>-Rasmus > >> > >>On Sat, 17 Aug 2002, Zeev Suraski wrote: > >> > >> > Just wondering - why are we even using atime? I think lots of filesystems > >> > don't support it, but regardless of that - as far as I recall from reading > >> > the session code, if a session is opened for reading - it is also going to > >> > be rewritten at the end of the session. So, it should be quite safe to > >> > check mtime instead of atime. > >> > Comments? > >> > > >> > Zeev > >> > > >> > At 04:03 17/08/2002, rasmus@php.net wrote: > >> > > ID: 3793 > >> > > Updated by: rasmus@php.net > >> > > Reported By: kori_mail@hotmail.com > >> > >-Status: Analyzed > >> > >+Status: Open > >> > >-Bug Type: Session related > >> > >+Bug Type: Documentation problem > >> > > Operating System: Windows 98 > >> > > PHP Version: 4 .1.2 > >> > > New Comment: > >> > > > >> > >I really don't see anybody with any interest in writing code to make > >> > >this work on FAT filesystems. Don't run web servers on crap > >> > >filesystems. If you do, write your own session handler. Same goes for > >> > >filesystems where file modification timestamps are ignored. Write your > >> > >own session handler and manage the garbage collection yourself. We'll > >> > >need to document this, of course, so marking this as a documentation > >> > >problem. > >> > > > >> > > > >> > >Previous Comments: > >> > >------------------------------------------------------------------------ > >> > > > >> > >[2002-07-10 05:10:43] jerome.billet@hcuge.ch > >> > > > >> > >I've exactly the same problem with Windows 2000, php 4.2.0 and apache > >> > >1.3 > >> > > > >> > >------------------------------------------------------------------------ > >> > > > >> > >[2002-03-31 03:49:43] bergmann@evisio.de > >> > > > >> > >After I tried about a week, by just setting the lifetime VERY high > >> > >(40000 first), maybe I can give a hint: > >> > > > >> > >With this very high value it worked, so I tried where exactly was the > >> > >critical point. It was somewhat about 32000. Slightly below, all > >> > >session files were deleted as described, slightly over not. But then > >> > >the error reoccurred with the same value. > >> > > > >> > >After some tries I found out the following: I set back the time on the > >> > >server one hour and it worked again. Here the times and the critical > >> > >points: > >> > > > >> > >At 9:24 local time : 30290 > >> > >At 10:28 : 34100 > >> > > > >> > >34100-30290=3810, which would be 63.5 minutes when interpretad as > >> > >seconds, which is the server's time difference... > >> > > > >> > >Since 10:28 means 37680 s since 0:00, there seems to be an additional > >> > >hour - maybe due to GMT setting (+1) I thought, but it was the > >> > >automatic daylight saving (or is it called summer time???) setting. > >> > >When turned off, at 9:45 the point was at 35100=9.75 hours... > >> > > > >> > >I hope that helps... ;-) > >> > > > >> > >-- mike > >> > > > >> > >------------------------------------------------------------------------ > >> > > > >> > >[2002-03-31 02:56:29] yohgaki@php.net > >> > > > >> > >It seems it never worked under windows. > >> > >Reopen > >> > > > >> > >------------------------------------------------------------------------ > >> > > > >> > >[2002-03-31 02:43:13] bergmann@evisio.de > >> > > > >> > >The reported errors are still in verson 4.1.2. > >> > > > >> > >System: w2k, CGI-version. > >> > > > >> > >------------------------------------------------------------------------ > >> > > > >> > >[2001-12-16 07:24:47] sander@php.net > >> > > > >> > >No feedback. Closing. > >> > > > >> > >------------------------------------------------------------------------ > >> > > > >> > >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/3793 > >> > > > >> > >-- > >> > >Edit this bug report at > >> > >http://bugs.php.net/?id=3793&edit=1 > >> > > >> > > >> > -- > >> > PHP Documentation Mailing List (http://www.php.net/) > >> > To unsubscribe, visit: > >> > http://www.php.net/unsub.php > >> > > > > > > >-- > >PHP Development Mailing List <http://www.php.net/> > >To unsubscribe, visit: http://www.php.net/unsub.php > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php >