then it should be fine. Replication won't bail for an
actually-doesn't-exist mailbox, but it can't fix broken mailboxes, that's what
reconstruct is for.
Bron.
On Thu, 11 May 2017, at 01:01, Eric Cunningham wrote:
Hi list, I'm running cyrus replication on cyrus 2.5.10. It seems
whenever a folder
successful reconstruct with "failed to read index header" for
every subfolder and "fatal error: Internal error: assertion failed:
imap/mailbox.c: 2847: record->size"
Any ideas on how to correct this so I can see if I can then get past the
replication error?
Thanks!
-
Just to close the loop on this, once the corrupted cdm-lit account on my
copy server successfully reconstructed, the backlog of replication has
completed successfully and is now caught up.
-Eric
On 05/11/2017 02:20 PM, Eric Cunningham wrote:
-G didn't seem to help, but I tried a "recons
underlying message (checks GUID
correctness). Reconstruct with -G should fix all possible individual
message issues, including corrupted data files.
On 05/11/2017 02:37 PM, Eric Cunningham wrote:
I have to walk this back. In looking slightly further back in my
logfiles, before every instance of
Hi list, I'm running cyrus replication on cyrus 2.5.10. It seems
whenever a folder is encountered in log-run that doesn't exist on the
client and/or the server, the replication process logs "Error in
do_sync(): bailing out! Bad protocol". Sometimes, it dies completely,
other times it
how! Oh well :(
Bron.
On Fri, 12 May 2017, at 04:55, Eric Cunningham wrote:
Just to close the loop on this, once the corrupted cdm-lit account on my
copy server successfully reconstructed, the backlog of replication has
completed successfully and is now caught up.
-Eric
On 05/11/2017 02:20 PM
Yes, file 148 is completely corrupted.
On 5/12/17 9:16 AM, Bron Gondwana wrote:
Just read the 148 file and see if there is corruption. I suspect that's the
cause.
Bron
On Fri, 12 May 2017, at 23:09, Eric Cunningham wrote:
I have snapshot backups of that account, that particular message
Hi list, I had a user report that their read message status was lost. I
recall having dealt with seen message db files in the past, but on my
current implementation (2.5 on FreeBSD 10.2), I'm not able to locate any
in or within my configdirectory, /var/spool/CyrusDB-Sieve/cyrusdb. I
have
rror.
Which sounds to me like we want to treat ECONNABORTED similarly to
EAGAIN, not as a fatal OS error. I'll have a patch up for this shortly.
Cheers,
ellie
On Wed, Oct 26, 2016, at 09:27 AM, Eric Cunningham via Info-cyrus wrote:
Having repeatedly experienced the "status 71" is
=
Eric Cunningham
Information Services - http://whoi-it.whoi.edu
Woods Hole Oceanographic Institution - http://www.whoi.edu
Woods Hole, MA 02543-1541 phone: (508) 289-2224
fax: (508) 457-2174 e-mail: ecunning
10 matches
Mail list logo
