[Kde-pim] multiple remoteIds in pimitemtable ?

[Daniel Vrátil]

On Sunday 20 of October 2013 18:04:08 Martin Koller wrote:
> Hi,

Hi,

> 
> I'm continuing my akonadi quest ...
> 
> I have a mailing list maildir folder, which contains KDE commit mails.
> In that I found 1 mail which appears a lot of times (ca. 570), so I checked
> the akonadi tables ... First I searched for that specific mail on disk, and
> I found exactly 1 mailfile: .../new/1378129436.R486.linux-d4d3.site:2,S
> What I see in pimitemtable when I search for that name:
> select * from pimitemtable where collectionId=223 and remoteid LIKE
> "1378129436.R486.%"; ...
> 572 rows
> 
> Question: Is it allowed (does it make sense) that pimitemtable contains
> multiple records with the same remoteid ?

Are all the remote IDs same, or does the part after R486. differ?

> what is the "rev" column for ?

rev == revision

With each modification, revision number of the item is increased. From the 
remoteID above I believe R486 means that the item has been modified 486 times. 
Something weird is happening, I only have few items with revision higher than 
100.

> 
> What I find strange is that nearly all these records include a wrong size
> value. The file on disk is really 3677 bytes and in most records I find
> 7100

The sizes should indeed match.

> 
> - only the records which have rev=0 hold the correct file size and
> remoteid=1378129436.R486.linux-d4d3.site:2,S and dirty=1 - all records with
> rev=1 have size=7100 and all of these have
> remoteId=1378129436.R486.linux-d4d3.site and dirty=0 - one record with
> rev=2 has size=7150
> 
> should the size value be the file size in bytes ?
> Because I find other records (also duplicated ones) where no single size
> entry is correct (e.g. file on disk=6348, size value in table=8101 or 9962)

This is weird. Maybe the file is somehow corrupted, or the maildir resource 
fails to correctly parse it?

> 
> Would it be possible to develop (or is there already) a tool which cleans
> the akonadi tables from such wrong records or to check whether the entries
> are still correct ?
> (Something like fsck for akonadi)
> Hmmm... I found that akonadictl already has the option fsck
> "Check (and attempt to fix) consistency of the internal storage (can take
> some time)" But running it here does neither take some time nor does it fix
> the above problems ...

The command only starts a job on the server and terminates immediately, while 
the job is running in the background for some time. However it does not detect 
duplicates, it only cleans up orphaned records and data files, so it won't help 
you much.

Dan

-- 
Daniel Vrátil
KDE Desktop Team
Associate Software Engineer, Red Hat, Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20131021/a5efdcb8/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/