Cyrus 2.3.10 RC3

[Bron Gondwana]

On Thu, Oct 18, 2007 at 03:04:06PM -0400, Ken Murchison wrote:
> I just put together a third release candidate for Cyrus 2.3.10 which
> fixes a couple of bugs, and hopefully resolves outstanding build issues 
> with com_err and xversion.  I'd appreciate any independent testing before I 
> release this to the masses.
>
> If there are any outstanding issues that you believe still need to be
> addressed in 2.3.10, please let me know ASAP.

So I suspect I'll be queueing up a "add crc32 to every single index
header, index record, cache record, etc" patch.

Annoyingly, it means that I'll have to add 8 bytes to each index
record because of alignment issues (ho hum - or maybe store the
crc32 of the cache record here too, stranger things have been
suggested.  Indeed, this means not having to add anything to the
cache format at all.  I'm liking it already!)

I pulled a bit of public domain code for the crc32 algorithm.
That's the easy bit.  Integrating CRC32 usefully will require:

* check the crc32 each time an index record is read.  I suspect
  a refactor is in order to make sure we don't do this every 
  single time we access a field, but also don't ever forget to
  do it at all.  I'd like to do away with the global #defines
  for index item access and replace them with (possibly inline)
  function calls anyway.  Then they could take a "sanitised"
  record pointer that had already been crc checked rather than 
  using a global pointer and "msgno" magic.

* any time any write is done to an index header or record, the
  crc32 of that record must be re-calculated and also written.
  I think we already always seek to the start and write an
  entire buffer with the necessary fields updated anyway, so
  this is probably only a couple of code changes (plus probably
  something tricky in sync_commit.c)

We're actually holding off a little on our 2.3.10 rollout after
the fun and games of my index upgrade going wrong on (I counted!)
72 mailboxes - probably because sync_server wasn't agreeing with
my code about locking - which is odd, because sync_upload_commit
was getting the locks in exactly the same order.  I'll have to
revisit my locking code and make sure it works!

Bron ( yay for consistency checking! )