Date: 08/17/02
- Next message: Zeev Suraski: "Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work"
- Previous message: goba <email protected>: "[PHP-DOC] #11598 [Fbk]: Configuration section doesn't distinguish between admin and user values."
- In reply to: Rasmus Lerdorf: "Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work"
- Next in thread: Rasmus Lerdorf: "Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Well, I guess it boils down to whether we want to support this function
(which should be easy, I think), or support filesystems without atime. I
vaguely remember that many filesystems don't have (or are capable of
disabling) atime for performance reasons, but I could be wrong. But, if
that's true, it may make sense to sacrifice the session-readonly
functionality in order to support non-atime compliant filesystems. It
should be a one character fix, if we decide to do it :)
Zeev
At 04:57 17/08/2002, Rasmus Lerdorf wrote:
>Well, the one problem with that is that, at least conceptually, there
>should be a way to use a session in a readonly manner. We even have a
>documented function for it:
>
>http://www.php.net/manual/en/function.session-readonly.php
>
>Of course, this function has been documented for ages and has never been
>implemented. This function would be useful actually.
>
>-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 <email protected> wrote:
> > > ID: 3793
> > > Updated by: rasmus <email protected>
> > > Reported By: kori_mail <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] jerome.billet <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] bergmann <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] yohgaki <email protected>
> > >
> > >It seems it never worked under windows.
> > >Reopen
> > >
> > >------------------------------------------------------------------------
> > >
> > >[2002-03-31 02:43:13] bergmann <email protected>
> > >
> > >The reported errors are still in verson 4.1.2.
> > >
> > >System: w2k, CGI-version.
> > >
> > >------------------------------------------------------------------------
> > >
> > >[2001-12-16 07:24:47] sander <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 Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
- Next message: Zeev Suraski: "Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work"
- Previous message: goba <email protected>: "[PHP-DOC] #11598 [Fbk]: Configuration section doesn't distinguish between admin and user values."
- In reply to: Rasmus Lerdorf: "Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work"
- Next in thread: Rasmus Lerdorf: "Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

