[Akonadi] [Bug 362699] Back end MySQL table PimItemTable shows entries with remoteID = NULL

[Christoph Pospiech via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362699

--- Comment #2 from Christoph Pospiech <pospiech-HD at t-online.de> ---
I just observed another 5 occurrences of RemoteID = NULL. I did some forensic
analysis. Hopefully the following observations help to pin down the problem.
1. Since I am running the akonadi database with my own MySQL server, I could
use phpMyAdmin to do some queries, starting from "SELECT * FROM `pimitemtable`
WHERE `remoteId` is NULL;"
I found that all these entries had a collectionID pointing to the trash can.
2. Apparently they were created by moving entries from an IMAP trash can to the
main trash can. The IMAP server was davmail 4.7.1-2416-1, used as an interface
to outlook.
3. There were three more entries put to the trash can by Kmail directly
    - these had a non-NULL RemoteID.
4. Emptying the trash can made the entries with RemoteID = NULL go away
    (no surprise, given what I said before).
5. I had a more emails in outlook that I could dispose. I repeated the
following experiment two times.
a. Inside outlook (running in a Win7 VM), put these emails into trash (one or
two at a time).
b. Wait for davmail to replicate the outlook trash into Kmail.
c. Run "SELECT * FROM `pimitemtable` WHERE `remoteId` is NULL;" and note the
result.
d. Move the emails from IMAP trash to main trash.
e. Rerun "SELECT * FROM `pimitemtable` WHERE `remoteId` is NULL;" and note the
difference.
=> One out of three emails disposed that way created a pimitemtable entry with
RemoteID = NULL.
=> This trash can scenario may not be the only one creating this effect. But it
is the least dangerous as these emails are to be disposed anyway - so no harm
done !

Hope this helps !
Christoph Pospiech

-- 
You are receiving this mail because:
You are the assignee for the bug.