> 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 > ---- 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
