On Thu, 1 Aug 2002, Simon Josefsson wrote: >Andreas Aardal Hanssen <[EMAIL PROTECTED]> writes: >>>should close it and then invoke STATUS UIDNEXT? >> If your whole session is opened only to check the status of a bunch of >> mailboxes, then yes, do not select anything. >No, I use one network connection for everything.
ok >> If you need to check the status while connected, then don't STATUS the >> current mailbox, because EXISTS from select() tells you how many messages >> there _were_ when you selected the mailbox, and "noop" will tell you how >> many arrived since then, and it will also often give you a new EXISTS. >Which doesn't give me the UIDNEXT. Yes it does. >>>now you are saying it doesn't work because I used STATUS on a selected >>>mailbox. If the latter is true, I think this should be documented. >> It does work, it does the job, but the information you have from your >> logged-in-session may be different from what STATUS gives you. And how can >> you know which one to trust? The truth is - you trust what your session >> tells you, and don't issue STATUS. >The session doesn't tell me UIDNEXT. >Should I trust a guess that UIDNEXT = 1+UIDMAX instead of what STATUS >UIDNEXT is telling me? Yes! For all you can use UIDNEXT for. >>>UIDNEXT. So again I'm not sure I see any text forbiding the use >>>STATUS UIDNEXT on the currently selected mailbox. >> Size == number of messages. select 1234:* UID gives you the highest UID >> number (last row). NOOP gives you "3 recent", and you add those numbers >> together. >Which isn't guaranteed to be correct, and when it is incorrect it >causes an unnecessary SELECT+FETCH on that mailbox. Ah, here's the problem. You seem to think that a UIDNEXT will ever be correct. How do you define "correct", considering that emails can arrive, get deleted, and so on and so forth continuously all the time? UIDNEXT is wrong the moment after a message arrives - and you can never know when that will happen. The fact is - the server gives you a state when you have selected a mailbox. This state you can trust, as long as you update it with any pending status updates. And I'm not talking about STATUS, but untagged status responses. So if you're in a mailbox and the last you heard was that the highest UID was 1234, and you haven't heard anything since then, then the only thing you can know is that if new messages have arrived, then they will have a higher UID. STATUS gives you a snapshot, in a select, untagged status responses give you current state. Unless you lock the whole depository some way, you can never know what UIDNEXT is. Andy >If I can't use STATUS UIDNEXT on the currently selected mailbox, the >solution I would lean towards is to unselect the current mailbox >(EXAMINE + CLOSE) and then invoke STATUS. This won't be slower than >SELECT+FETCH, and my clients' internal structures will have correct >information. The downside is that EXAMINE+CLOSE is slightly slower >than guessing 1+UIDMAX. >>>>>My original mail contained two problems though, the second one being >>>>>not able to select INBOX in that state. Any ideas on that one? >>>> You didn't close the first mailbox first, did you? >>>No, I didn't want to expunge the mailbox. SELECT + SELECT is legal. >> >> You pasted this into your original mail yourself, from 6.4: >> >> In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), >> and the authenticated state commands (SELECT, EXAMINE, CREATE, > ^^^^^^ >> DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and >> APPEND), the following commands are valid in the selected state: >> CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID. >> >> Is SELECT allowed in selected state? > >Yes. > > -- Andreas Aardal Hanssen
