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, [EMAIL PROTECTED] wrote: > > ID: 3793 > > Updated by: [EMAIL PROTECTED] > > Reported By: [EMAIL PROTECTED] > >-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] [EMAIL PROTECTED] > > > >I've exactly the same problem with Windows 2000, php 4.2.0 and apache > >1.3 > > > >------------------------------------------------------------------------ > > > >[2002-03-31 03:49:43] [EMAIL PROTECTED] > > > >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] [EMAIL PROTECTED] > > > >It seems it never worked under windows. > >Reopen > > > >------------------------------------------------------------------------ > > > >[2002-03-31 02:43:13] [EMAIL PROTECTED] > > > >The reported errors are still in verson 4.1.2. > > > >System: w2k, CGI-version. > > > >------------------------------------------------------------------------ > > > >[2001-12-16 07:24:47] [EMAIL PROTECTED] > > > >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