SELECT / Squirrelmail issue
brong at fastmail.fm
Sun Oct 17 04:38:44 EDT 2010
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)
> * 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.
More information about the Cyrus-devel