SELECT / Squirrelmail issue

[Bron Gondwana]

On Sun, Oct 17, 2010 at 02:16:21AM -0400, Carsey, Robert wrote:
> On one which did not work, I found:
> . SELECT INBOX
> * 76 EXISTS
> * 0 RECENT
> * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
> * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] Ok
> * OK [UNSEEN 1] Ok
> * OK [UIDVALIDITY 0] Ok

Ok.   Seriously WTF???  UIDVALIDITY 0?  How did that even get created?

> * OK [UIDNEXT 1189] Ok
> * OK [HIGHESTMODSEQ 1] Ok
> * OK [URLMECH INTERNAL] Ok
> * 1 FETCH (FLAGS () UID 110)
> * 2 FETCH (FLAGS () UID 561)
> * 3 FETCH (FLAGS () UID 796)
> * 4 FETCH (FLAGS () UID 797)
> ...cut...
> * 76 FETCH (FLAGS () UID 1188)
> . OK [READ-WRITE] Completed
>
> What are all these FETCH lines?  Why would they appear for one inbox and not another?  (I'm trying to read through the RFCs to see if this is expected/normal stuff)... otherwise, im having a hard time figuring out if this is a Cyrus issue or a SM incompatibility issue somehow.

Well, the UIDVALIDITY 0 means something is pretty bogus.  Along with
HIGHESTMODSEQ 1 it pretty much means the index header is nonsense,
and the code is throwing fetch data for every record in the hope that
it brings the client back into sync.
 
> I've even wiped out all of this user's cyrus.* files and reconstruct -r  them

Even their cyrus.index file?  And it's still creating this bogus UIDVALIDITY?
Unless something's odd with your clock I don't see how this could happen.

Bron.