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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
