Re: Item "255451" in collection "108" has no RID.
test <[email protected]>
| Newsgroups | gmane.comp.kde.users.pim |
|---|---|
| Message-ID | <[email protected]> |
On Friday, May 8, 2020 10:31:05 AM CEST Martin Steigerwald wrote: > Dear Achim, dear René, dear community, > > Achim Bohnet - 08.05.20, 10:05:32 CEST: > > On Thursday, 7 May 2020 20:58:16 CEST René J.V. Bertin wrote: > > > On Thursday May 07 2020 20:01:21 test wrote: > > > >'akonadictl fsck' gives lots of messages like in the subject. Are > > > >those bugs, and if so, how can I fix them? > > > > > > I can't comment on what they are, but I don't think you can fix them > > > if the command that's supposed to fix issues cannot. What you can > > > try is a "vacuum", which should clean out your database, after > > > which messages are reloaded from the remote server (when you launch > > > KMail). With a bit of luck that will get rid of the offending > > > whatever-they-are. > > > > One can use akonadiconsole to get rid of them. Start akonadiconsole > > > > * Read the warning that pops up carefully. > > * tab 'DB Browser': select collectiontable, press [refresh] > > > > -> check with name collection id 108 has > > > > * tab 'Browser' select the collection with the name you found in > > > > the step above. Sort list of the right hand side by 'Remote ID' > > (list all item with no RID grouped together) or scroll to the ID > > > > 255451 * Inspecting the payload shows you the content and may give > > you a hint how to reproduce the problem for a bug report > > > > * Right click on the item -> delete > > > > Now at least akonadictl fsck is happy. > > This always worked for me. > > Interesting idea, never considered to delete them this way. > > Thing is, "fixing" it this way can cause data loss. Why? > > "Item without RID" as discussed here quite some time ago are items that > Akonadi was not able to store into the resource. For example with IMAP a > mail it got, but was not able to store onto the IMAP server. For example > with maildir, a mail it got, but was not able to store onto the > filesystem. > > I do not understand how this can ever happen with maildir, however it > *does* happen. > > Now Akonadi *does not* try again. So the item, for example the mail, > *may* be *just* in the database and *nowhere* else. In that case, if you > delete it from the database, the item it lost. How do I know if the message is still in the database? > So, before deleting it, did you make sure you have the item *in* the > resource, i.e. on the IMAP server for example or in the maildir? How do I know if the message is still on the IMAP server? Even if kmail were to show me message numbers, I wouldn't know if kmail shows the numbers the IMAP server uses or others. > Due to this I have chosen to ignore those messages for now, hoping that > one day Akonadi will gain the ability to retry replaying the changes to > the resources. > > And yes, this is a FAQ, and this is known for a long, long time. I hope > someday a developer will fix this. I believe there is a bug report open > at it - well at least one – but I do not recall specifics at the moment. I'm getting the feeling that whatever database kmail is using is somewhat broken. Can't I just use mariadb instead, which is running on a server on the network anyway?