Are we in agreement? Paul's patch (bug #2866) actually unexpunges the
messages. I thought that folks we arguing that cyrus.expunge and the
references messages should be left alone and omitted from cyrus.index.
I agree, left alone is the way to go. Really a reconstruct on a valid
mailbox sh
The only problem is that you really want "globally" unique id's.
We've seen a couple of cases with reused uniqueid's (probably our fault
with some of the messy stuff we do at the low level), and it really
stuffs up replication. To get globally unique, you'd have to check every
cyrus.header
Just reviving an old issue to see if anyone has any more information.
http://asg.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-devel&msg=1072
We still see this every now and then, most often with seen state databases.
It's most often after an unclean shutdown, but I've seen it at other
When restarting (e.g. after the crash) the transaction is not rolled back
in
every case --> corruption.
Yes, we've seen that. It's annoying, though not deadly so far since it's
only been seen state databases.
Workaround: Switch to BDB.
I trust BDB a lot less than the skiplist db. I've see
We've seen corruption caused by 2 diferent sources:
- fail on allocation of memory: linux can negate mmap's with plenty of
memory free. There was a patch to use remap instead of unmap / mmap again,
but we never tested it;
- there is some sort of race, that shows up in (real) smp boxes (dont
> 1) Pro:
> * simple to calculate - only updated by cyr_expire
"simple" seems good :)
> 1) Con:
> * Higher bandwidth use in the "stale client" case.
If you're not syncing that often, then there's probably enough other
stuff that needs downloading that it'll swamp the bandwidth anyway.
> 2)
> Yeah - I think I've decided on (1) with a syslog every time it gets a
> request that triggers a stale client sync - that way sites (like us!)
> can see how much they're getting stale syncs, and can decide to either
> extend their expiry time or agitate to have (2) implemented!
I like it :)
Rob
> It doesn't really matter for a seen_bigdb, because they'll be keyed by
> user AND uniqueid - meaning they are no more likely to generate
> clashes than they were before under seen_db.
Ah yes, good point!
> Besides, they only matter within the non-user folders now.
Yeah, but just because most
(Resending to include cyrus-devel)
> > At the moment, the storage format in use is iCalendar, being stored as
> > RFC5322 messages.
>
> That sounds very much like what Kolab did in version 1.
>
> After trying to make this interoperate for several years it was given
> up in favor of the Kolab XM
> I want to check how many people out there would be interested on
> RFC5703 support in Cyrus IMAP, that is, Sieve Email Filtering: MIME
> Part Tests, Iteration, Extraction, Replacement, and Enclosure.
>
> See: http://tools.ietf.org/html/rfc5703
Any improvements to cyrus sieve support would be h
> a) add modseqs and tombstones everywhere
It's interesting how once this was in cyrus.index (tombstones = records
previously in cyrus.expunge), it was *clearly* right, and now that it's
not on any of the other meta data, how much it sucks trying to handle
deletes and/or updates on both sides. Th
> Alt External Non-Alt External Internal
> Inbox INBOX user.foo
> Inbox.sub INBOX.Inbox.subuser.foo.Inbox.sub
> INBOX.sub INBOX.INBOX.subuser.foo.INBOX.sub
> INBOX.INBOXuser.foo.INBOX
> INBO
> This assumes that the ability of setting this special annotation also
> means the server will honor it. Probably a save thing to do with the
> current implementations. But this gives this detection two small
> drawbacks:
This is still way better than your current solution which was to look
for
FYI a user of ours encountered this recently and we came to the
conclusion it's a Thunderbird bug. An edited conversion I had with Bron
is below.
Checking the Thunderbird bugzilla, I see multiple reports of this. In
particular a bug that was supposedly fixed in 2010 seems to have
recently re-appea
> If the client's connection has dropped out, no data will ever appear on
> the socket, so select will never flag it as readable, so we will never
> try to read from it, so we will never receive the read error even though
> tcp_keepalive detected the dropout. And if this client was idling with
>
> The thing is, during IDLE, we're not blocked on a read, we're blocked on
> a select (in idle_wait()). We don't even try to read from the client
> until the select tells us it's readable. If the client has dropped out,
> select never tells us it's readable, so we never try to read, so the
> time
> Back in imapd.c, cmd_idle() only reads from the client socket if
> IDLE_INPUT is flagged. Which it's not after a select timeout, so if
> tcp_keepalive has detected a connection dropout, cyrus still doesn't
> know about it.
So tcp_keepalive and select() timeout are unrelated. It appears the
poi
17 matches
Mail list logo
