in reply to Re: Re: Cleaning up sessions created by Apache::Session::File when logging out of a CGI application
in thread Cleaning up sessions created by Apache::Session::File when logging out of a CGI application

Well, if you look carefully at the code for the clean method, you will see that it has a bug as well... The culprit is on line 136 of Apache::Session::Lock::File:

if ((stat($dir.'/'.$file))[8] >= $time) - $now {

This says: take the last access time of the lock file, subtract the current time and see if it is bigger than the proposed timelimit ($time). Since the current time will always be bigger than the last accees time, this number will always be negative. So unless you provided a negative timelimit to the clean function, the condition for deletion will never be met. Reversing the subtraction should fix the problem.

if ($now - (stat($dir.'/'.$file))[8] >= $time) {

Or you could pass a negative time limit to the clean method, but that could break if this bug ever gets fixed and you upgrade.

Now, again I will try to convince you to scrap the File based sessions and move to at least the DB_File based one.

  • Comment on Re: Re: Re: Cleaning up sessions created by Apache::Session::File when logging out of a CGI application
  • Select or Download Code

Replies are listed 'Best First'.
Re: Re: Re: Re: Cleaning up sessions created by Apache::Session::File when logging out of a CGI application
by Joey The Saint (Novice) on Feb 10, 2003 at 19:31 UTC

    Thanks, I'd tried passing a negative value to the time limit as a last act of desperation before posting that, but it didn't seem to help, though I suspect -1 wasn't adequate for the task.

    And don't worry, I'm already convinced to use the DB_File approach. I'd really rather not introduce a dependency on something like MySQL, but DB_File shouldn't be a problem. The only reason I asked about the lock files is that Apache::Session::DB_File also takes a LockDirectory value in the same way ::File does, so I anticipated I'd have the same problem. Next time I'll try it before posting, though.

    -J.