[solved] Corrupted database, needs clean install database

tjoen

kopanocore-8.6.80.1420 only server, dagent and gateway running

# cat server.cfg | grep -v "^#" | grep -v ^$
server_listen = *:236
local_admin_users = root kopano
mysql_user = kopano
mysql_password = kopano
disabled_features = pop3

exim
fetchmail
evolution-3.28.4 not relinked after updating Gnome, openssl, webkitgtk

Yesterday two emails. one normal readable. The second one has the wrong content when opened in message panel, it shows a deleted email
Test message to myself same: In inbox-panel visible but in message-panel an other deleted email.
Sloved by dropping kopano database and recreating.
This morning 228 emails normal redable, but same problem with two emails from same sender as yesterday
Test email same problem, database corrupted again
This time I have kept the emails on the server of my ISP. On webmail of my ISP I can read both messages
Saved both messages as .eml but I see nothing strange

Message-ID: <050CD4C3B2AD48BF9676C80B6B4DE2AD@Goan01>
From:  "edited" <edited@edited>
To: "Tjoen Oei" <tjoen@dds.nl>
Subject: Re: Deconstructivisme
Date: Sun, 7 Oct 2018 23:02:25 +0200
MIME-Version: 1.0
Content-Type: text/plain;
        format=flowed;
        charset="iso-8859-1";
        reply-type=response
Content-Transfer-Encoding: 7bit
Importance: Normal

Schilderij Banksy, ik moest aan jou denken.

Both webmail and Evolution don’t show the first from-line as this example I saved a time ago

From hilmlopiz@hotmail.com Mon May 14 08:01:51 2018
Return-path: <SRS0=Kb0m+ytX=IA=hotmail.com=hilmlopiz@srs.dds.nl>

etc

Strange that email only from one person is causing this problem

fbartels

Hi @tjoen,

that sounds a bit strange. Some followup questions to this.

@tjoen said in Corrupted database, needs clean install database:

kopanocore-8.6.80.1420 only server, dagent and gateway running

quite a while ago you were asking about running Kopano in LFS is that such a self made build or are you running with our packages (some more recent replies at least suggest you looked at our packages).

@tjoen said in Corrupted database, needs clean install database:

exim
fetchmail
evolution-3.28.4 not relinked after updating Gnome, openssl, webkitgtk

and

@tjoen said in Corrupted database, needs clean install database:

when opened in message panel

just that I fully understand. you are seeing this in an imap client, right? So you are not using Kopano WebApp.

@tjoen said in Corrupted database, needs clean install database:

database corrupted again

if you are indeed using imap, then this may not be a corrupt database after all. For performance reasons since Zarafa 6.40.0 a copy of the full rfc message is stored in the attachment dir. elements in the attachment dir are identified by an “instance id”, which is a simple auto incrementing value. so if you get a wrong item displayed via imap a good test would be if you also get the same wrong item via webapp.

If that isn’t the case (in webapp you see the right object), then something must be wrong with your attachments. this usually only happens if users modify the files in there manually (restoring older backups (attachments do not match highest instance id), restoring backups and having items deduplicated with hardlinks).

tjoen

@fbartels

quite a while ago you were asking about running Kopano in LFS is that such a self made build or are you running with our packages (some more recent replies at least suggest you looked at our packages).

That was with that MAPI-error. Yes, I have tested in Fedora-28 witch had the same error. Solved by kopanocore-8.6.80.1420

@tjoen said in Corrupted database, needs clean install database:

evolution-3.28.4 not relinked after updating Gnome, openssl, webkitgtk
when opened in message panel

just that I fully understand. you are seeing this in an imap client, right? So you are not using Kopano WebApp.

Evolution as IMAP-client. Most simple configuration is using Kopano as Dovecot replacement, only running server, dagent and gateway. For WebApp more configuration is needed, including kopano-spooler

if you are indeed using imap, then this may not be a corrupt database after all. For performance reasons since Zarafa 6.40.0 a copy of the full rfc message is stored in the attachment dir.

If that isn’t the case (in webapp you see the right object), then something must be wrong with your attachments. this usually only happens if users modify the files in there manually (restoring older backups (attachments do not match highest instance id), restoring backups and having items deduplicated with hardlinks).

That is a good suggestion. I see that the default behaviour is storing attachments.
I’ll delete all attachments before recreating the database. And ask the sender of the problem-email to send a test email.

tjoen

Deleting attachments before recreating the database was indeed the sollution.