Updating /seen from concurrent sessions

Andrew McNamara andrewm at object-craft.com.au
Thu Nov 14 01:50:05 EST 2002


Outlook Express users are complaining that their message \Seen status is
"lost". Snooping traffic, I see that OE is opening a second connection. In
duplicating OE's behaviour by hand, I'm finding that I'm more confused
than ever about Cyrus's behaviour. We're using Cyrus 2.1.9 on NetApp
mounted disk.

First up, a description of what OE is doing (in all it's stupidity) - when
you read a message, it uses BODY.PEEK so as not to update the \Seen flag.
It then apparently closes that connection, opens another, and sets the
\Seen status with "xxx UID STORE 49 +FLAGS.SILENT (\Seen)". It then
forgets that connection, and opens a new connection and starts using
that for accessing the mailbox.

At the Cyrus end, this is useless - the Cyrus that accepts the \Seen
update, but holds off updating the .seen file (presumably as a performance
optimisation). So the second session doesn't see it until OE eventually
closes the first connection. Even sending a NOOP on the \Seen-updating
thread would have been enough to trigger Cyrus into updating the .seen
file. Cyrus probably needs to update the .seen file if no other activity
occurs for a second or two.

But - there appears to be a second problem: even if OE had sent a NOOP
(or Cyrus decided to write the file), the second session doesn't see
the update - it's still holding open an old .seen file, now unlinked
(by the rename() that the \Seen-updating thread did). Cyrus needs to
periodically stat() the .seen file and compare it's inode number to that
of the file it holds open - if the differ, it needs to reopen the file).

The RFC isn't entirely helpful on who's at fault here - section 5.5 talks
about multiple commands being allowed, provided ambiguity doesn't result.
In this case, provided OE waits for the STORE command to complete, I guess
it's within it's rights to check the message status from another session.
It's largely irrelevant anyway - OE is out there, and getting it "fixed"
would be a hiding to nothing.

I realise this is an old known problem, but I've spent some time searching
list archives, and other sources looking for an answer. Any help anyone
can provide will be gratefully received.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/




More information about the Info-cyrus mailing list