You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Daniel Quinlan <qu...@pathname.com> on 2004/02/23 05:19:25 UTC

why ctime for stale lock deletion?

Shouldn't we be using mtime for this?

    # check age of lockfile ctime
    my $now = ($#stat < 11 ? undef : $stat[10]);
    @stat = stat($lock_file);
    my $lock_age = ($#stat < 11 ? undef : $stat[10]);
    if (!defined($lock_age) || ($now - $lock_age) > LOCK_MAX_AGE) {
      # we got a stale lock, break it
      dbg("lock: $$ breaking stale $lock_file: age=" .
          (defined $lock_age ? $lock_age : "undef") . " now=$now");
      unlink ($lock_file) || warn "lock: $$ unlink of lock file $lock_file failed: $!\n";
    }

Also, we might want to add a trap such that if a process is killed while
waiting for a stale lock, it will delete it on its way out.

Daniel

-- 
Daniel Quinlan                     anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/    and open source consulting

Re: why ctime for stale lock deletion?

Posted by Theo Van Dinter <fe...@kluge.net>.
On Sun, Feb 22, 2004 at 08:19:25PM -0800, Dan Quinlan wrote:
> Shouldn't we be using mtime for this?

Unless I'm missing something, it shouldn't matter really.  The last time
the file changed should be == the last time the inode changed.

-- 
Randomly Generated Tagline:
tmps_base = tmps_max;                /* protect our mortal string */
              -- Larry Wall in stab.c from the perl source code