[Akonadi] [Bug 406856] Found 3734 items without RID.; Item "30024" has RID and is dirty.

[Martin Steigerwald]

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

Martin Steigerwald <Martin at Lichtvoll.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |Martin at Lichtvoll.de
             Status|REPORTED                    |CONFIRMED

--- Comment #2 from Martin Steigerwald <Martin at Lichtvoll.de> ---
Nick, thank you for your report. I can confirm that this is happening.

You may clear up the fsck messages about "item has no RID" with the queries you
stated, however… as far as I understand Akonadi assigns a RID once it stored
the item in remote storage. For IMAP this would be the IMAP account and for
Maildir resource it would be the Maildir. And right now Akonadi's change
recorder has no means to retry this failed operation. So items may never end up
in the remote storage! Additionally for Maildir I do not get how this operation
to store into (the quite local) remote storage could ever fail, as long as the
filesystem has enough space.

So it could be that those items without RID have not yet been stored to the
remote storage and that by deleting them from the database (and if payload
stored externally from 'file_db_data') you loose those items (mails, events,
contacts, …). So there is a real potential for data loss there.

However it also could be that Akonadi just messes up big time like in storing
the items into remote storage, but somehow failing to store the remote ID or
whatever. I just recently switched from MariaDB to PostgreSQL and already got

"Found 43 items without RID."

as well as

"Moved 6882 unreferenced files to lost+found." (will do a separate bug report
about that, since it actually did not even move those files), after just a few
weeks of usage. This is with POP3 filling maildir.

One thing: On delays during background jobs I sometimes just did "akonadictl
stop" and then as PostgreSQL is not stopped completely on my system (yet
another bug report), also stop the PostgreSQL process, so this may contribute
to the situation. Did you do something similar at times?

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