akonadictl fsck: What messages indicate real issues and what to do about them?

Martin Steigerwald <[email protected]>
Newsgroups gmane.comp.kde.users.pim
Message-ID <1578910.soeygQTm3H@merkaba>
Hello.

After Akonadi was still occupied with stuffing all the 67000+ mails of the 
maildir folder I just moved inside KMail between different parent folders of 
the same and only maildir resource, I did a akonadictl stop to stop that 
madness. On next start of Akonadi it luckily forgot what it was about to do. I 
used akonadictl fsck to clean out the mess in file_db_data + db_data and that 
it did.

However even now it still reports some other issues I am not sure about. So I 
ask here: What messages indicicate real issues and what can I do about them?

I am first asking here, but I am willing to provide bug reports for any real 
issues. I store a copy of this fsck run. I don´t provide it in full here due 
to privacy concerns.

# Collections without RID

> Looking for dirty objects...
> Collection "Search" (id: 1) has no RID.
> Collection "OpenInvitations" (id: 395) has no RID.
> Collection "DeclinedInvitations" (id: 396) has no RID.
> Found 3 collections without RID.

I think at least for "Search" this is expected. I am not sure about the other 
two, but it may be expected for them as well.

# Items without RID

> Item "1289323" has no RID.
> Item "1289324" has no RID.
> Item "1289325" has no RID.
> Item "1289326" has no RID.
> Item "1289327" has no RID.
> [… more than 1800 more …]

RID is Remote ID as far as I understood. Yet the remote here is the local 
maildir. So these appear to be items in the database or file_db_data that are 
not inside the maildir. How can I look up these items and check whether this 
is an issue?

# Items with RID that are dirty

> Item "1335889" has RID and is dirty.
> Item "1349287" has RID and is dirty.
> Item "1349736" has RID and is dirty.
> Item "1360764" has RID and is dirty.
> Item "1360766" has RID and is dirty.
> [… easily more than 2000 …]

What about these?

# RID duplicates not matching the content mime-type of the parent collection

What?

> Looking for rid-duplicates not matching the content mime-type of the parent
> collection

Some examples:

> Checking akonadi_icaldir_resource_0
> Found duplicates
> 040000008200E00074C5B7101A82E00800000000201B33D46D12D2010000000000000000100
> 0000085F61ED021447341AA2A15976A6B8FA7

> Checking aros-dev-ml
> Found duplicates 1429563277.R787.merkaba
> Found duplicates 1432116953.R995.merkaba
> Found duplicates 1436178221.R34.merkaba

> Checking oss-security-ml
> Found duplicates 1424451476.R127.merkaba
> Found duplicates 1424451476.R255.merkaba
> Found duplicates 1424453279.R126.merkaba
> […]

Lots more.

Seriously, I am not even sure I want to understand what this is about. But 
well… what is it about?

I think its good for fsck to provide more helpful messages:

1. If its no issue, then don´t report it unless "-v" is given.

2. If its an issue, advice what to do about it.

Thanks,
-- 
Martin
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.