On Mon, Jun 11, 2001 at 02:42:33PM -0700, Randall Gellens wrote:
> At 8:14 AM -1000 6/11/01, Clifton Royston wrote:
> > > If so, this is a bug. The .user.pop file is also used as a
> >> mutual-exclusion lock to prevent more than one POP session at the
> >> same time.
> >
> > How does that work together with keeping it permanently around as a
> > zero-length file?
>
> Qpopper locks it with flock() or fcntl().
OK, that makes more sense now.
> The presence of the file
> doesn't mean a session is active, because it's possible for a
> Qpopper process to die (especially 2.x) or be killed, which would
> leave the .user.pop file behind in any case.
I think then that the bug might be the assumption that flock() or
fcntl() by themselves will affect the file change time - which is what
our scripts look at - or that something else in the process of things
will touch the file. I've been trying to read pop_dropcopy.c and
pop_updt.c, and it looks like success on some logic paths will result
in the p->hold file pointer (which is where the .user.pop file ends up
in server mode) never being written into, just fclosed at the end of
the session.
I'm not quite sure of the best place to fix it, though.
-- Clifton
--
Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED]
WWJD? "JWRTFM!" - Scott Dorsey (kludge) "JWG" - Eddie Aikau
