Исправление записей KMail «в обработке»

Проблема напрямую связана с ошибкой Akonadi #436550, которая стала известна в апреле 2021 года. Эта проблема является результатом записей «в обработке», случайно обнаруженных в akonadictl fsck.

~ $ akonadictl fsck 2
>&1 | grep ^Found
Found 5 external files.
Found 5 external parts.
Found no unreferenced external files.
Found 0 parts to be moved to external files
Found 0 parts to be moved to database
Found 6 collections without RID.
Found 0 items without RID.
Found 750 dirty items.

Флажок «в обработке» для элементов в pimitemtable (одна из таблиц базы данных Akonadi) используется для управления некоторыми аспектами асинхронной обработки. Для него устанавливается значение «true», когда есть операции для определённого письма. Чаще всего флажок «в обработке» удаляется через одну-две секунды после того, как заканчивается соответствующая операция.

По не совсем очевидным причинам флажок «в обработке» может быть установлен для десятков и даже сотен писем, как было показано выше. Когда такое происходит, автоматический механизм чистки флажков «зависает» и не может восстановиться. Основная причина появления флажка «в обработке» в таком случае является то, что программа неправильно устанавливает значение поля «remoteid», что делает получение флажка «в обработке» в KMail невозможным, несмотря на то, что письмо всё ещё находится на диске, но KMail не может его найти.

Возможно, у этой проблемы есть лучшее решение. Если вам удалось решить её оптимальнее, сообщите об этом авторам документации, чтобы усовершенствовать её. Приведённый ниже метод поможет исправить ошибки в базе данных, но он требует довольно много ручной работы.

  1. Закройте KMail и остановите сервер Akonadi с помощью команды в терминале: akonadictl stop .

  2. Создайте резервную копию всех своих электронных писем, для этого рекомендуется воспользоваться экспортом данных PIM. Либо возможно воспользоваться Ark для создания архива или Dolphin для создания копии каталога ~/.local/share/local-mail/ где-нибудь на жёстком диске. Наиболее смелые пользователи могут просто переименовать каталог локальных папок в что-нибудь наподобие local-mail-save . Убедитесь в наличии резервной копии своих писем перед тем, как продолжить.

  3. Рекомендуется также создать резервную копию всех созданных фильтров и убедиться в возможности восстановить созданные вручную папки отправленной почты, папки черновиков или папки шаблонов, связанных с профилями KMail. На следующем шаге все пользовательские папки почты будут удалены. поэтому придётся кое-что исправлять после того, как Akonadi перестроит свои таблиц базы данных.

  4. Теперь удалите все папки в каталоге local-mail или переименуйте каталог как-нибудь, например, local-mail-save. Запустите KMail. Это заставит Akonadi удалить все записи базы данных, связанные с электронной почтой. Отобразятся другие названия папок, но они исчезнут, когда Akonadi закончит удалять все элементы «в обработке» (и вообще все элементы).

  5. Закройте KMail и остановите работу сервера Akonadi, как показано в шаге 1, затем восстановите резервную копию писем, созданную в шаге 2 в каталоге ~/.local/share/local-mail/.

  6. Снова запустите KMail и принудите Akonadi повторно синхронизировать базу данных. Наиболее простой способ сделать это — это воспользоваться пунктом меню ФайлПроверить почту (Ctrl+L); Akonadi автоматически повторно синхронизирует все папки при получении писем. Это займёт несколько минут в зависимости от того, сколько писем было сохранено в папках KMail. Когда процесс обновления будет завершён, все элементы «в обработке» исчезнут.

  7. Последний этап — восстановление правил фильтрации почты, резервная копия которых была создана на шаге 3, а также проверка, правильно ли установлены параметры всех собственных папок (Папка отправленных писем и так далее) для используемых профилей. Потребуется сбросить все свойства вручную созданных папок. Кроме того, возможно появление уведомления о непрочитанных письмах, которые тоже нужно будет убрать. Зато таблицы базы данных Akonadi снова будут чистыми.