http://docs.kde.org/
FöregåendeFelsökning i KMailNästa

Korrigera KMails "smutsiga" objekt

Problemet är direkt relaterat till Akonadi fel nr. 436550, som rapporterades april, 2021. Det orsakas av de "smutsiga" objekten som ibland hittas av 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.

Flaggan "dirty" för ett objekt i pimitemtable (en av tabellerna i Akonadi-databasen) används för att hantera vissa aspekter av asynkron behandling. Den tilldelas true när åtgärder väntar för ett specifikt e-postbrev. Oftast nollställs flaggan "dirty" en eller två sekunder senare, när den väntande åtgärden avslutas.

Ibland, av orsaker som inte är helt klargjorda, kan flaggan "dirty" tilldelas till dussintals eller till och med hundratals brev samtidigt, som åskådliggörs ovan. När det inträffar, fastnar den automatiska mekanismen för att nollställa dem, och kan inte reparera sig själv automatiskt. Den primära orsaken för ett "smutsigt" objekt i detta fall är att fältet "remoteid" inte är riktigt inställt, vilket gör det omöjligt att hämta ett "smutsigt" brev i KMail. Brevet finns fortfarande på disk, men KMail kan inte hitta det.

Det borde finnas ett bättre sätt att korrigera problemet. Om du kommer på ett bättre sätt, låt författarna få reda på det, så att dokumentationen kan förbättras. Följande procedur rättar åtminstone databasfelen. Men den innebär en hel del arbete.

  1. Avsluta KMail och stoppa Akonadi-servern med ett terminalkommando: akonadictl stop.

  2. Skapa en säkerhetskopia av alla dina e-postbrev. Du kan kanske använda Export av data för personlig informationshantering för att göra det. Eller så kan du använda Ark för att skapa ett arkiv, eller Dolphin för att skapa en andra kopia av ~/.local/share/local-mail/ någon annanstans på hårddisken. Om du är äventyrlig, kan du bara byta namn på din lokala korgkatalog till något som local-mail-sparade. Men det är säkrare att försäkra dig om att det finns en säkerhetskopia av dina brev innan du fortsätter.

  3. Du bör också göra en säkerhetskopia av eventuella filter du har skapat, och säkerställa att du vet hur man återställer eventuella egna korgar med Skickade brev, Utkast eller Mallar som hör ihop med dina identiteter i KMail. Nästa steg tar bort alla dina personliga anpassade brevkorgar, och du måste laga en del efter Akonadi har byggt om sina databastabeller.

  4. Ta nu bort alla korgar under katalogen local-mail, eller byt namn på katalogen till något som local-mail-sparade . Starta därefter programmet KMail. Det tvingar Akonadi att radera alla databasens tabellposter som hör ihop med e-postbrev. Du ser dina gamla korgnamn under en kort tid, men de försvinner när Akonadi är klar med att ta bort alla "smutsiga" objekt (och även alla rena).

  5. Avsluta KMail och stoppa Akonadi-servern som förklaras under steg 1, återställ därefter säkerhetskopian av dina brev (skapad i steg 2) i katalogen ~/.local/share/local-mail/.

  6. Starta KMail igen, och tvinga Akonadi att synkronisera om databasen. Det enklaste sättet att göra det är att använda Arkiv → Kontrollera post (Ctrl+L). Akonadi synkroniserar automatiskt alla korgar när nya brev hämtas. Det tar flera minuter att slutföra, beroende på hur många brev du har sparat i dina KMail-korgar. Men när processen är färdig har alla "smutsiga" objekt försvunnit.

  7. Slutligen, ska du återställa dina e-postfilterregler säkerhetskopierade i steg 3, och kontrollera att alla egna korgobjekt (Skickade brev, etc.) är inställda som du vill ha dem. Du måste också återställa eventuella egna korgegenskaper du hade ställt in, och du har troligen ett antal felaktiga underrättelser om "olästa brev" att ta hand om. Men dina Akonadi databastabeller är riktigt rena och snygga igen!