It's a restriction, and it's permanent. Snarfing requires RW access, and EXAMINE by definition is RO.
Use STATUS or EXAMINE, but don't use both. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. > Date: Sat, 6 Sep 2008 22:10:12 +0200 > From: [EMAIL PROTECTED] > To: [email protected] > Subject: [Imap-uw] Unix INBOX in /var/mail, mbx INBOX in home, snarf problem. > > > I have small problem with "snarf" functionality of mbx driver of > c-client. The IMAP client (Horde, here) issue the following sequence of > commands: > >>>> STATUS INBOX (MESSAGES RECENT UNSEEN UIDNEXT UIDVALIDITY) > <<< STATUS INBOX (MESSAGES 6 RECENT 0 UNSEEN 6 UIDNEXT 16 UIDVALIDITY > 1212640213) > >>>> NOOP > <<< OK NOOP completed > >>>> EXAMINE INBOX > <<< 5 EXISTS > <<< 0 RECENT > <<< OK [UIDVALIDITY 1212640213] UID validity status > <<< OK [UIDNEXT 15] Predicted next UID > <<< FLAGS (\Answered \Flagged \Deleted \Draft \Seen) > <<< OK [PERMANENTFLAGS ()] Permanent flags > <<< OK [UNSEEN 1] first unseen message in /home/dan/INBOX > <<< OK [READ-ONLY] EXAMINE completed > > The status report 6 messages, EXAMINE reports only 5. NOOP shall update > IMAP servers status with current content of mailbox. > > In the fact, there are 5 messages in MBX ~/INBOX and one in > /var/mail/ > > The STATUS command is based on results of mbx_status() function which > count messages in both ~/INBOX and /var/mail/... mailboxes. > > The NOOP do nothing, because the folder is opened read-only. > > The EXAMINE return data from ~/INBOX only (opened RO). > > As a result the client write "You have 6 messages; Displaying 1..5 of 5 > > The unix's mbx driver never snarf if client doesn't request RW access to > INBOX (and client doesn't request RW access to INBOX unless it want to > change it which is not the case of pooling for changes). > > It seems to be bug - driver shall snarf (from time to time) even if > client request RO access only. > > As a workaround I created a daemon which do "snarfing" by self, > independently of imap/ipop daemons. > > Well - that is problem description. Now question - did I miss something > in the configuration and the described problem is only my problem or > it's the real problem of mbx driver ? > > I searched the FAQ and list archives, but it seems I'm alone with such > problem ... > > Dan > > > > By the way: OS - FreeBSD, IMAP-UW version 2006j (but the relevant parts > of 2007d mbx driver code seems to be same as in 2006j) > _______________________________________________ > Imap-uw mailing list > [email protected] > http://mailman2.u.washington.edu/mailman/listinfo/imap-uw _________________________________________________________________ See how Windows connects the people, information, and fun that are part of your life. http://clk.atdmt.com/MRT/go/msnnkwxp1020093175mrt/direct/01/_______________________________________________ Imap-uw mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
