You are using traditional UNIX mailbox format, which only allows one
process to access it at a time. All locks in traditional UNIX mailbox
format are exclusive. You are correct that status updates in that format
are postponed until the next checkpoint (check, expunge, or close) but
that doesn't matter because only one process is accessing it.
From your description, it sounds like either you, or your client, are
spawning a second process to access the mailbox. This second process
smashes the exclusive lock held by the first process, thus cancelling
everything that the first process did, in order to seize the lock for
If you are wondering why UW imapd does this, it is so that if you forget
and leave your client running in the office and go home, you can get to
your mail. Without the lock-smash procedure, you wouldn't have access to
your mail until you get back to the office.
However, it seems that some badly-written IMAP clients assume that if a
lock is exclusive, it will stay held and prevent a second process from
breaking the lock. Therefore, these poorly-written clients rationalize,
it is alright to spawn a second IMAP session to do something like check
for new mail, since the lock will just cause an error. Then, when their
client does this bad thing, they blame the server.
There is no reason, other than a lazy programmer, for a client to spawn
multiple sessions to the same mailbox. The IMAP protocol makes it
UW imapd supports other mailbox formats which allow multiple access, and
then you won't see the effect of the poorly-written client. Or you can
use a well-written client, such as Pine or Mulberry.
-- Mark --
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.