FastMail.FM Patchset Updated

[Simon Matter]

> As usual you can get the patches here:
>
> http://cyrus.brong.fastmail.fm/
>
>
> I've been busy with Cyrus _again_ - so much for my theory
> that I was taking a break.
>
> OK - here's what's new.
>
> *
> http://cyrus.brong.fastmail.fm/patches/cyrus-skiplist-bugfixes-2.3.10.diff
>   http://cyrus.brong.fastmail.fm/patches/cyrus-skiplist-robustify-2.3.10.diff
>
>   Skiplist issues - there were two things that could be found
>   in recovery that actually bit us during the whole "restart
>   every single store with the new skiplist code" project the
>   other day.  ADD where the record already existed and DELETE
>   where it didn't.  The later also had an obnoxious bug where
>   it would instead delete _the_alphabetically_NEXT_record_
>   silently.  Ooops.
>
>   I rolled these two into my bugfix and robustify patches, not
>   realising Ken had already applied the previous copies upstream.
>   Ken - do you want me to break this out as a separate patch on
>   top of the others?
>
> *
> http://cyrus.brong.fastmail.fm/patches/cyrus-sync-renamedmailbox-2.3.10.diff
>
>   DelayedDelete of entire users was causing excess copying.
>   This fixes it, but the solution is less than ideal and causes
>   excess messages about folders not existing during an account
>   create.  Annoying.  I'd like a better fix, but this is enough
>   for now.  Found this one after fixing...
>
> *
> http://cyrus.brong.fastmail.fm/patches/cyrus-deletemode-userfix-2.3.10.diff
>
>   This is for upstream.  I made a bogus design decision in the
>   DelayedDelete code that Ken accepted, and it was causing
>   bailouts and all sorts of yuckyness.  Made the conditions for
>   allowing a folder rename into the DELETED. namespace a lot more
>   explicit and correct rather than DELETED.user.foo.TIMESTAMP
>   being considered a user's mailbox!  The user cleanup script
>   no longer causes massive bailouts on sync.

Hi Bron,

Did you consider this one
http://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3006 in the patch above?
>From a quick look it seems both patches conflict, is #3006 obsolete now?

Thanks,
Simon

>
> *
> http://cyrus.brong.fastmail.fm/patches/cyrus-expunged-nocache-2.3.10.diff
>
>   A little thing to shut up the issue that used to cause segfaults
>   and now just causes logging instead.  Cache offsets in the .expunge
>   file can be bogus for deeper architectural reasons.  Rather than
>   fix the underlying reasons I just ignore them completely when
>   running cyr_expire.  At least that way we're not reading bogus
>   cache records.
>
> * http://cyrus.brong.fastmail.fm/patches/cyrus-fastrename-2.3.9.diff
>
>   UPDATED.  It turns out it really doesn't matter what YOU can see
>   when you're checking if you can use FastRename.  It matters if
>   there are subfolders at all.  Change to passing isadmin true
>   and not passing the username to mboxlist_count_inferiors().
>   Also need to check if the target path has inferiors to avoid
>   log messages and partial move failures that have to back out.
>   Much nicer this way.  This means fastrename on replicas isn't
>   totally broken any more (before, it would never see the subfolders
>   because the replication user didn't have ACLs on them and isadmin
>   was being set to false explicitly)
>
>
> Ken - I'd love to see the deletemode-userfix and skiplist stuff
> go upstream.  I know you're not happy with fastrename yet, and
> fair enough - it's an extra risk and if a shutdown happens in
> the middle of the operation things can get very confused!  The
> other two patches are not really long-term good for the Cyrus
> codebase so I'd prefer to fix the underlying issues instead :)
>
> Bron.
> ----
> Cyrus Home Page: http://cyrusimap.web.cmu.edu/
> Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
> List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
>