Bug#321102: more ways to reproduce this bug
Hi Adam,
Adam Porter schrieb:
> I'm not sure if doing dIMAP atomically would make sense; that sounds like
> regular, online IMAP to me. The whole point of dIMAP is to make changes
> offline and then sync them all at once. (Although the reason I use dIMAP is
Atomic means that an operation which consists of more than one atomic
step must follow the all-or-nothing principle. This means if one of the
steps fail, it must undo all other involved steps.
This does not contradict the way how DIMAP works. In fact it's still
perfectly possible to delay/queue the move operation when in offline
mode, but *when* the operation happens, it has to be atomic. This is the
only way to guarantee that the data keeps consistent and no data is lost.
An example: moving a mail consists of two steps: KMail has to copy the
file from A to B and remove the remaining file on A. If one part of
"move" fails, then you have either a duplicated file on the source- and
the target folder (delete fails) or your file is lost (copy fails).
If one of those two steps fails the other has to be undone in order to
keep the data consistent.
If it's not possible to implement move to be atomic it should be at
least guaranteed that no file is *lost* (eg. copy first and delete
afterwards). A duplicated file is a problem the user can cope with a
deleted is not.
One main problem of this bug is that the user does not actually *notice*
that his mail is lost when an accident happens. He moves a mail, sees
the desired result inside of KMail but does not know that actually his
mail is already gone on the server side. This makes the bug so dangerous.
Cheers,
Bastian
--
Bastian Venthur http://venthur.de
Debian Developer venthur at debian org
Reply to: