[Kde-pim] Re: Review Request: Recover from unknown UID after APPEND or COPY

[Volker Krause]

> On April 18, 2011, 5:41 a.m., Kevin Ottens wrote:
> > I probably lack some insight there, how a random RID will help ItemSync clean up that particular ghost item? (I understand the empty RID protection reasoning, I'm just not aware of the logic in ItemSync which would help locating that this particular item with a random RID is to be removed).
> > 
> > Also, unit test please?

If the item has an RID and does not exist on the server (which with the UUID-like random RID it will never do) it's removed locally, thus cleaning up the mess. Well, at least when using ItemSync in non-incremental mode, which the IMAP resource does when not using fast sync, it's the same way we deal with remote deletions.


- Volker


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101147/#review2712
-----------------------------------------------------------


On April 17, 2011, 4:39 p.m., Volker Krause wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101147/
> -----------------------------------------------------------
> 
> (Updated April 17, 2011, 4:39 p.m.)
> 
> 
> Review request for KDEPIM.
> 
> 
> Summary
> -------
> 
> Currently, if unable to determine the UID of a message after an APPEND or COPY command, we abort the task and leave the Akonadi item with an empty RID. During the next sync, the message we added to the server is discovered and downloaded, duplicating it locally. Items with empty RIDs are protected against deletion during a sync, since they are assumed to not be on the server yet. This is a safety feature, but gets in to the way of automatic recovery here.
> 
> So, this patch fixes this by assigning an arbitrary random RID in this case. Note that this only happens if all UID detection attempts fail, not if e.g. the actual APPEND or COPY failed. Assuming that those commands report errors correctly, this should be safe.
> 
> 
> This addresses bugs 259214 and 264266.
>     http://bugs.kde.org/show_bug.cgi?id=259214
>     http://bugs.kde.org/show_bug.cgi?id=264266
> 
> 
> Diffs
> -----
> 
>   resources/imap/additemtask.cpp d686a2a 
>   resources/imap/moveitemtask.cpp 15e1cf6 
> 
> Diff: http://git.reviewboard.kde.org/r/101147/diff
> 
> 
> Testing
> -------
> 
> None, unfortunately, I cannot trigger this code path here since I have no access to a non-UIDPLUS server.
> 
> 
> Thanks,
> 
> Volker
> 
>

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/