On Mon, 2005-09-12 at 09:52 -0400, Todd Vierling wrote:
On Sun, 11 Sep 2005, Timo Sirainen wrote:
The error message means that Dovecot saw a message 1187 that wasn't in index, but index said it already had seen message 1188. Probably means that the file was temporarily lost in some sync, but later seen again in another sync.. Dovecot isn't very forgiving if readdir() skips files.
Reading your statement above again, something sounds odd here. If UID 1187 is not in index, how does dovecot even know that the message file in question is UID 1187? (This sounds very much like an ordering problem of some sort.)
There's also dovecot-uidlist file which keeps the filenames there for a bit longer.
Yes, the order isn't relied on. The filenames are all read into a hash table which is used.
Then by "skips files" you mean that a file is disappearing and reappearing? I don't know how that could be, as it would make many other programs on the system go insane....
If you're getting a list of files in a large directory using readdir() but at the same time there are rename()s and/or unlink()s happening in the same directory, the readdir() can skip over some files.
It just hit me again, and now I realize that there is a common behavior pattern happening. In every case that this has happened, I have been deleting large numbers (>10) of messages from a mailbox. IIRC, in Maildir flags are expressed as filename additions, so a rename(2) is happening.
Thanks, that helped me enough to reproduce it. Fixed in CVS now.
Problem was that sometimes Dovecot updated new next_uid to index file even while it hadn't actually added the new mails to index file (because it was doing a "partial" syncing, which is done when maildir file is lost and we're trying to find it again).