[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pop3d and imap4d's locking behaviour

From: Sam Roberts
Subject: Re: pop3d and imap4d's locking behaviour
Date: Fri, 1 Mar 2002 23:41:34 -0500
User-agent: Mutt/1.3.16i

Did some more reading, and it looks like mbox_scan0() is
trying to lock the mailbox, its just ignoring the return
value of locker_lock(). But just changing that seemed to
slow down the select, I'll keep looking.


Quoting Sam Roberts <address@hidden>, who wrote:
> 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!)
> _______________________________________________
> Bug-mailutils mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-mailutils

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]