On Thu, 25 May 2006 08:43:46 -0400, "Ken Murchison" <murch@xxxxxxxxxxxxxx> said: > This hole mess is a result of me having my head up my ass. I usually do > pretty thorough testing of any code that I touch, and I *thought* that I > had done that with the CONDSTORE stuff. Its now obvious that I didn't > do enough testing of the non-CONDSTORE case. Happens to us all :( Of course, as Rob suggested, a regression test suite means you don't _have_ to think so much about things that worked in the past. Not entirely so, because your test suite is unlikely to cover every use case, but it should help a lot. We're a bit in the same boat - far too much of our system doesn't have test suites, and even when we do test stuff there's inevitably something different about production. At least we've moved to a relatively stable Debian based infrastructure now where you can get pretty much an entire server running with 'apt-get install fastmail-base; svn co $URL; make -C conf install'. Not quite there yet, but that's the goal. Means we're testing in an environment that's a much like production as we can make it and things don't get littered with as many ad-hoc changes. I hope my emergency patch is useful to you. I seems to have solved the obvious symptoms for us. Of course you probably know better than me if there's anywhere else that's generating index files that needs updating to set that struct member. Possibly a safer approach (bit late now, I know) is to have an init_index function which is _always_ called on one of those structs _before_ you do anything else to it, and then when you add a member to the struct you only need to do the default case in one place (new_index.modseq = 1;). That would have avoided the need to litter the code with bits of initialiser everywhere. There's my object-oriented training talking. We've moved most of our staff accounts (including me!) onto the server that is running 2.3.5+patches so we can eat our own dogfood. Mmm.... dogfood. Should help us see if anything else is strange. (now I just have to figure things out so that when we move users we retain the UIDVALIDITY so my entire offlineimap store doesn't get stale next time) Bron. -- Bron Gondwana brong@xxxxxxxxxxx ---- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html