Subject: mail_status() and stream->nmsgs

From: "Syd Logan" <[email-masked]>
Date: Tue, 4 Mar 1997 17:38:50 -0800

-----BEGIN PGP SIGNED MESSAGE-----

Hi folks...

Periodically, I call mail_status() on my open IMAP4 stream to obtain a count of
messages. Every so often the number of messages that is reported by c-client is
different (and larger) than what is stored in stream->nmgs. The problem is that
my code executes a loop based upon the reported number of messages, calling a
mail_*() function which in turn calls mail_elt(). Mail_elt() range checks the
message number, and calls fatal() because the specified message number is too
high.

I tried following the c-client docs which suggest clients never call mail_elt()
without first calling mail_fetchfast() or mail_fetchstructure() first, but both
of these call mail_elt() and will fail as well.

Note that mail_elt() changed in the recent release - the previous release only
checked that the message number was 1 or greater.

It may be important to note that I only see this problem if I have two MUAs
polling for new messages from the same mailbox on the same IMAP4 host.

Closing the mailstream down, reopening it, and calling mail_status() again
*always* gets me the right answer, but is pretty painful. I am wondering if
c-client should be updating stream->nmsgs with the mail_status() - reported
value.

Regards,

syd

-- 
Syd Logan
Senior Software Engineer, Z-Mail for Unix
NetManage, Inc.

http://www.users.cts.com/crash/s/slogan

My PGP public key is available at:

http://www-swiss.ai.mit.edu/~bal/pks-toplev.html - search for "Syd Logan"

---

From: Mark Crispin <[email-masked]>
Date: Tue, 4 Mar 1997 21:03:39 -0800 (PST)

You are confused by what mail_status() does, and by how shared access works.

mail_status() does *NOT* report on the status of the open mailbox on the
stream.  It reports on the status of some other mailbox.

The only time that you use mail_status() is when you want to find out about a
mailbox that is *NOT* open.  mail_status() is very likely to open another
stream on the mailbox, parse the entire mailbox, and close that stream.

To find out what messages exist on an open stream, use stream->nmsgs.  When
the stream is able to get at additional messages, stream->nmsgs will update
automatically.  You'll also get an mm_exists() event.

> polling for new messages from the same mailbox on the same IMAP4 host.

If you are using standard UNIX format on the IMAP server, then the IMAP server
of the second MUA killed the read/write access of the first MUA's IMAP server.
The first MUA will no longer get updates.

You can *NOT* have multiple IMAP servers with read/write/update access to the
same UNIX format mailbox.  You will never be able to do it with standard UNIX
format.  IMAP is just a protocol.  It can't perform magic on a mailbox format
that is designed for exclusive access.  If you want shared read/write/update
access, you *must* use another mailbox format.

I know that I'm sounding like a broken record, but once again this is why we
don't use standard UNIX mailbox format.  We want shared read/write/update
access.

> *always* gets me the right answer, but is pretty painful.

mail_status() is an advanced operation, not for c-client novices.  When you
start doing things such as multiple mailbox scans (e.g. TAB in Pine's folder
collection menus), then you need mail_status().  But until that time,
mail_status() is not useful for you, so please forget that it exists.

> I am wondering if

No, it shouldn't.  stream->nmsgs is the status of what the stream knows, not
about what some external thing such as mail_status() had to say.

To summarize:

1) Forget about mail_status().  It does not do what you want, and the way you
    are misuing it you are wasting of CPU time and memory.
2) Use stream->nmsgs and/or mm_exists() events to let you know how many
    messages you can access on the stream.
3) Do not attempt to have multiple sessions to the same UNIX-format mailbox.
    If you ignore this advice and start multiple sessions, all but the last
    started one will be read-only and not get any updates.  You can tell that
    this happened because stream->readonly got set when it wasn't.
4) This is a permanent problem with UNIX-format mailboxes.
5) Certain other formats of mailbox do not have this problem.  They can get
    updates when multiple sessions to the same mailbox are in progress.  They
    can also get updates when they are read-only.