Re: Akonadictl fsck

On lunes, 21 de marzo de 2016 9:30:05 (CET) Martin Steigerwald wrote:
> 
> This means this is a potential data loss issue?
> 
> Sure, Akonadi keeps it in the database, but really, if Akonadi is primarily
> a cache it has to flush them out, not even on explicit request, but I´d say
> it has to try itself again.
> 
> I really think Akonadi better treats the backend storage as final location
> for any items it stores.
> 
> Any plans about changing this behavior?
> 
> I am surprised that Akonadi still has reliability issues like this.
> 
> First priority I think should be to never *ever* loose any user data. For
> that reason I think the database is not acceptable as a final destination.
> 
> I am willing to write a bug report about that, so that this doesn´t get
> lost, but first I want to make sure I really understood it.
> 
> Thanks,

Martin,

Would it be bug #339181?

I stoped using disconected imap because moving more than one mail from a 
disconnected imap resource to a local mail resource always left items in an 
akonadi cache limbo.

If you know in which resource the problematic items are, you can *copy* (NOT 
move) these items to another resource and you will get a copy in the final 
destination. You can inspect where the items live browsing the database with 
akonadiconsole.

Unfortunately this bug makes me not trust akonadi, I read mails with imap 
resources in kmail, and I archive them in local resources, but the movement 
form the imap resource to the local one is done with fetchmail+procmail.

Luis

_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users