[kdepim-users] Akonadictl fsck

[Martin Steigerwald]

On Montag, 21. März 2016 19:48:35 CET Daniel Vrátil wrote:
> On Monday, March 21, 2016 6:41:12 PM CET Martin Steigerwald wrote:
> > On Montag, 21. März 2016 10:17:12 CET Luis Felipe Tabera Alonso wrote:
> > > 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?
> > 
> > Jep, its exactly that, if you ask me.
> > 
> > Bug 339181 - moving mails from cached imap to local folder leaves mails
> > without RID
> > 
> > 
> > I even commented in there.
> > 
> > Thank you for bringing it up.
> 
> I can't reproduce it. One of the comments mentions that the maildir folder
> is not created on the harddisk - if that's the case, then obviously we
> can't store the emails to the disk either, and we can't assign Item a
> remote ID until we can write it to the storage...
> 
> Martin, can you confirm that the destination folder exists on your disk?

I didn´t report this bug.

Thanks,
-- 
Martin