The whole point of RO access, and the EXAMINE command, is to "make no changes". Snarfing is a change. In particular, one use of EXAMINE is as a system management tool.
As a convenience (and a convenience only), the STATUS command reports what would happen if RW access were to happen, since the most common use of STATUS is to probe to see if there is new mail in a non-open mailbox. The "bugfix" would be to remove that convenience from STATUS. But then STATUS would be less convenient, and less useful. Since it is more useful to have the "bug", that is why the bug is there. -- 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: Sun, 7 Sep 2008 12:59:42 +0200 > From: [EMAIL PROTECTED] > To: [email protected] > Subject: Re: [Imap-uw] Unix INBOX in /var/mail, mbx INBOX in home, snarf > problem. > >>> I have small problem with "snarf" functionality of mbx driver > >>> 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 > > > Mark Crispin napsal/wrote, On 09/07/08 08:26: >> Snarfing requires RW access, and EXAMINE by definition is RO. > > Snarfing require RW access to both folders (~/INBOX and /var/mail/) > and client ha access (either RW or RO) to one of them only. Despite of > it, snarfing can obtain requied RW access to /var/mail/ and copy the > messages even the EXAMINE has NO access to it ... > > It seems to be restriction "by decision" that the same driver can't > raise ~/INBOX access level to RW just for the time of snarfing (then > revert back to RO according client's wishes). Not every time, but from > time to time. > > It's about reopening stream as RW and upgrade shared lock to exclusive, > isn't it ? > > But it's not complaint to code author in any way - just notice from > newbie that may not be familiar of all the internals ;-) > >> It's a restriction, and it's permanent. > > No problem if I know it. I wroted own snarfing daemon so I'm not limited > by restricted snarfing implementation of MBX driver. > > Such restriction shall be mentioned in documentation... > >> Use STATUS or EXAMINE, but don't use both. > > Did you know I'm not the author of all IMAP clients flying around the > world ? ;-) > > Nothing in the specification forbid the simultaneous use of SELECT and > EXAMINE nor warn that the commands may return inconsistent results so it > will be hard to push the world to change. > > By the way - even if I use EXAMINE only, I will not see the new messages > so it's "problem still exists but you will not see it on the first look" > workaround > > > Well. You confirmed my analysis - it's most interesting for me just now. > If I know the restriction then I can do something with it. > > Thank you very much for your reply. > > Sincerely > > > Dan > _______________________________________________ > Imap-uw mailing list > [email protected] > http://mailman2.u.washington.edu/mailman/listinfo/imap-uw _________________________________________________________________ Stay up to date on your PC, the Web, and your mobile phone with Windows Live. http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/_______________________________________________ Imap-uw mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
