Cache truncation bug on aborted appends

[Bron Gondwana]

On Fri, 5 Dec 2008 08:25:38 +0100 (CET), "Simon Matter" <simon.matter at invoca.ch> wrote:
> > Hi all,
> >
> > Cyrus stores the end of the cache file before starting an
> > append operation so that it can truncate back to that point
> > if the append is aborted.
> >
> > Unfortunately, it actually stores cache_len rather than
> > cache_size.  That sort of sucks, because cache_len is
> > rounded up by quite a bit to allow "slop".  As the cache
> > file gets bigger, the slop gets bigger too, and you wind
> > up with a whole pile of zero blocks in your cache file,
> > making it (even if sparse) somewhat massive.
> >
> > Oh, and the bogus record(s) that you wrote are going to
> > still be (possibly only partially) in the file, because
> > the truncate will either be past them, or in the middle
> > of them.
> >
> > This is exacerbated by the fact that duplicate suppression
> > seems to need to write to the cache file _before_ it decides
> > not to accept the message!
> >
> > The attached patch fixes the issue, adds a comment, and
> 
> Hi Bron,
> 
> is there something missing in the patch, because I can't see the "adds a
> comment" part?

Hmm... could be.  Damn.  I'll just go back and have a look.  I did the
comment after the rest of it - it's pretty meaningless anyway.  The code
in the patch is certainly fine...

Ok - here's the copy with the comment!

Bron.
-- 
  Bron Gondwana
  brong at fastmail.fm

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cyrus-truncate-length-2.3.13.diff
Type: text/x-patch
Size: 1444 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20081205/fe3d7a16/attachment.bin