Hello,
I'm tracking the cvs repository and managing our local patches with
git, when I went to rebase our patches on 2.3.15 I noticed there
wasn't anything in cvs tagged as that version. Just wondering if
that's intentional or if it was overlooked?
Thanks,
Brian
On Wednesday 26 August 2009 @ 21:42, Bron Gondwana wrote:
I have a fix for that which avoids the hilarity. It's in that
queue, and it makes all cache accesses go through one API which
does bounds checking.
I updated my clone of your git repository and took a look at the
changes. Having an
On Thursday 27 August 2009 @ 22:30, Bron Gondwana wrote:
Yeah - it does make a bit more sense when you put it like that.
Does it make 8 bytes per record worth of sense though? (we need
to pad to 8 byte multiples for 64 bit modseq alignment.) I'll have
another look at that in a second.
It
Lately we've been chasing cache file issues here pretty regularly and
we just found something yesterday that might indicate what's
occurring. While I like the idea of keeping a checksum of the
records, it probably won't solve the issues we are seeing.
It seems to probably relate to delayed
On Wednesday 20 May 2009 @ 19:28, Bron Gondwana wrote:
I approve of all these ideas.
Great!
+while ((opt = getopt(argc, argv, C:kp:rmfsxgGwe)) != EOF)
{
+if( config_getenum(IMAPOPT_EXPUNGE_MODE) ==
+ IMAP_ENUM_EXPUNGE_MODE_DELAYED ) {
+ keepflag = 1;
+}
The
On Friday 06 February 2009 @ 12:27, Brian Awood wrote:
We have had users that weren't able to delete a mailbox that was
close to, or already at, the max name length. Cyrus generates the
new name with the DELETED prefix and time stamp suffix, which ends
up being longer than the allowed max
On Saturday 14 March 2009 @ 17:45, Bron Gondwana wrote:
On Sat, Mar 14, 2009 at 05:03:22PM -0400, Brian Awood wrote:
On Friday 13 March 2009 @ 22:12, Bron Gondwana wrote:
Man, that's going to hurt against my cache rewrite code, which
was written in response to a bug report of a crash
We have had users that weren't able to delete a mailbox that was close
to, or already at, the max name length. Cyrus generates the new name
with the DELETED prefix and time stamp suffix, which ends up being
longer than the allowed max and the rename then fails.
No idea where 490 came from,
as well. Also,
since @ is normally allowed in GOODCHARS, it seems the above code could
trigger unexpected behavior for people even if they are using the
standard GOODCHARS.
---
Brian Awood
University of Michigan
ITCS
On Tuesday 30 September 2008 @ 22:15, Wesley Craig wrote:
On 30 Sep 2008
