MBOX-Line: From dave at cridland.net  Mon Dec 31 16:45:27 2012
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:50 2018
Subject: [Imap-protocol] Missing UIDNEXT during mailbox synchronization
In-Reply-To: <20121231133118.Horde.U5PPDhJmrIJk-ldhlJw3KQ1@bigworm.curecanti.org>
References: <db123879-1082-4911-b7ce-3a861d62217a@flaska.net>
	<20121228112725.Horde.cM7EjLQoqQDix9dQMs5KcA1@bigworm.curecanti.org>
	<1356723190.15576.140661171078629.69B791C0@webmail.messagingengine.com>
	<20121228130129.Horde.VTgbGtjlIvg0wUwlkp5dDg6@bigworm.curecanti.org>
	<1356732787.18647.140661171122177.5EB821AB@webmail.messagingengine.com>
	<1356733058.19335.140661171123477.7DDFF57D@webmail.messagingengine.com>
	<20121231133118.Horde.U5PPDhJmrIJk-ldhlJw3KQ1@bigworm.curecanti.org>
Message-ID: <CAKHUCzy_uRyj_GgpzuAg_EMaCeD1uoizY_yVBVgF3YD+qM0qUw@mail.gmail.com>

On 31 Dec 2012 20:32, "Michael M Slusarz" <slusarz@curecanti.org> wrote:
> Why not?  The stored UIDNEXT != the cached UIDNEXT.  So something is up
and the client should issue FETCH's to retrieve further information.
 UIDNEXT's have nothing to do with the actual next assigned UID, so I don't
care if it is incrementing or decrementing.  It only matters if it is
different.
>

Kind of. If size less cached size equals uidnext less cached uidnext, there
have been no expunges.

>> . uid fetch * (uid)
>> . OK Completed (0.000 sec)
>
>
> I may have mis-typed before.  A UID FETCH * is not useful - it should be
a FETCH * (UID) used instead to determine the last UID in the mailbox.  And
if the mailbox is empty, I agree that the actual UIDNEXT value can't be
determined.  In our client, we clear the UIDNEXT and cache so the next time
a message is seen the cache is restart/rebuilt.

Uid fetch * (uid) is the same as Fetch * (uid).

For updating a msgno/uid mapping, you want uid search. Ideally with return
(all), though in practise,  I doubt there are any servers that don't do
qresync but still do esearch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130101/c91cb975/attachment.html>
