[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
POP3d locking
From: |
Alain Magloire |
Subject: |
POP3d locking |
Date: |
Mon, 23 Apr 2001 20:43:54 -0400 (EDT) |
Bonjour
> Finally, what seems to be a real problem is simultaneous access to
> the maildrop. All locking/unlocking works just fine, but I have
> come across the following situation: two sessions access the same
> mailbox simultaneously, both do LIST, then one of them does
> DELE on some message, then QUIT. The remaining session does a RETR
> and dies miserably, since its internal indices are already out of sync
> with the real maildrop contents. The comment on mbox_is_updated()
> function addresses this but the function itself is never called.
> So I added a call to mailbox_is_updated() to the pop3_mainloop()
> function just before the processing of a keyword. Also I have added
> ERR_MBOX_SYNC define to help handle the situation when
> mbox_is_updated() bails out.
> After these changes, the second session just gets the message
>
> -ERR Mailbox updated by other party or corrupt
>
> and the connection is closed. This behaviour seems to be compatible
> with RFC, but maybe it would be better to deny simultaneous
> accesses altogether?
Good question.
The RFC just says:
the POP3 server then acquires an exclusive-
access lock on the maildrop, as necessary to prevent messages from
being modified or removed before the session enters the UPDATE state.
If the lock is successfully acquired, the POP3 server responds with a
positive status indicator. The POP3 session now enters the
TRANSACTION state, with no messages marked as deleted. If the
maildrop cannot be opened for some reason (for example, a lock can
not be acquired, the client is denied access to the appropriate
maildrop, or the maildrop cannot be parsed), the POP3 server responds
with a negative status indicator. (If a lock was acquired but the
POP3 server intends to respond with a negative status indicator, the
POP3 server must release the lock prior to rejecting the command.)
Which I find annoying, because some POP session can be rather
lengthy.
So:
1- Your popose solution.
2- Follow the RFC, and completely lock the mailbox for the entire session.
3- The Qualcomm solution (QPopper) which is to move the mailbox to a new
location ${SPOOLDIR}/.user.pop for the duration of the session.
I vote for -1- until we found a better mechanism.
We could still play it smart and keep the connection alive
if we know that the mailbox did not __shrank__ but only __grow__
(new messages delivered).
--
alain
- sieve, and header_t's api, Sam Roberts, 2001/04/22
- Re: sieve, and header_t's api, Alain Magloire, 2001/04/22
- Message not available
- Re: sieve, and header_t's api, Sam Roberts, 2001/04/23
- Re: sieve, and header_t's api, Alain Magloire, 2001/04/23
- Bug in mapfile_stream.c, Sergey Poznyakoff, 2001/04/23
- Sergey(patch mbx_mbox.c), Alain Magloire, 2001/04/23
- POP3d locking,
Alain Magloire <=
- Re: POP3d locking, Sergey Poznyakoff, 2001/04/24
- Re: POP3d locking, Alain Magloire, 2001/04/24
- Re: POP3d locking, Sergey Poznyakoff, 2001/04/24
- Re: POP3d locking, Alain Magloire, 2001/04/24
- Re: POP3d locking, Sergey Poznyakoff, 2001/04/24
- Re: POP3d locking, Alain Magloire, 2001/04/24
- Re: POP3d locking, Sergey Poznyakoff, 2001/04/24
- Re: POP3d locking, Alain Magloire, 2001/04/24
- Re: sieve, and header_t's api, Alain Magloire, 2001/04/24