[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.
Sam
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!)
- pop3d and imap4d's locking behaviour, Sam Roberts, 2002/03/01
- Re: pop3d and imap4d's locking behaviour,
Sam Roberts <=
- Re: pop3d and imap4d's locking behaviour, Sam Roberts, 2002/03/02
- Re: pop3d and imap4d's locking behaviour, Alain Magloire, 2002/03/02
- Re: pop3d and imap4d's locking behaviour, Sam Roberts, 2002/03/02
- Re: pop3d and imap4d's locking behaviour, Alain Magloire, 2002/03/02
- Message not available
- Re: pop3d and imap4d's locking behaviour, Sam Roberts, 2002/03/03
- Re: pop3d and imap4d's locking behaviour, Alain Magloire, 2002/03/03
- Message not available
- Re: pop3d and imap4d's locking behaviour, Sam Roberts, 2002/03/04
- Re: pop3d and imap4d's locking behaviour, Alain Magloire, 2002/03/05