pop3d and imap4d's locking behaviour

[Sam Roberts]

Bonjour,

I notice that imap4d doesn't do any locking other than what
the underlying mailbox does.

pop3d locks and keeps a lock on the mailbox, but only touches
it when it after receiving an input line from the client.

mbox doesn't lock the file at all before scanning, but in
mbox_scan0() it touches the lock every 100 messages (if it
checked the return value, it would discover that it doesn't
hold the lock).

This doesn't seem right... it seems like since both servers
just call the underlying mailbox_* functions (I assume), they
should do things similarly. What's going on?

I think that the mailbox should always be locked at the begining
and end of mbox_scan0().

If imap4d can just use the locking that the mbox does, then
pop3d should be able to as well, shouldn't it?

If pop3d IS supposed to hold a lock, and update it, then it
should select on stdin with a timeout, and update at half the
period of the default timeout used by MU_LOCKER_TIME.

The default lock method now is MU_LOCKER_RETRY, so it won't
remove a lock, but it will retry for 10 seconds. The idea
is that multiple mail tools (pop, imap, an MUA on the local
spool) won't fail immediately if some other program has the
spool locked. As long as everybody just locks the spool while
they are reading it or writing it, and leaves it unlocked the
rest of the time, this should allow pretty seamless interop.

However... if you lock the spool, you can still connect to
imap4d, it will happily read the spool, you can then delete
a message, and quit. You'll get no error, but it won't delete
the file, or mark it as deleted.

I don't know what the right thing to do here is, but I'm
concerned that imap4d appears (to me using mutt) to silently
drop changes if it couldn't lock the box, and that pop3d
doesn't seem to trust the mbox_ code enough to let it
do the locking, but imap4d does.

Cheers,
Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)