Message duplication

[Sebastian Spaeth]

On Wed, 22 Jun 2011 13:49:27 +0200, Vincent Beffara wrote:
> Yes, it does sound a little convoluted ... shouldn't the message have a
> number already assigned by the IMAP server in the first place ? Or is
> there a risk of duplicated numbers ?

Yes, the source IMAP server already has an UID assigned, then we upload
it to the dest IMAP server who also returns another UID to us. The UID
mapping does nothing but relate those two numbers so we know it is the
same message.

If you lose the UIDMapping, offlineimap has no way of knowing that a
message is already synced and you would end up with duplicated messages
on both sides if you resync afterwards (at least no lost messages).

> Just to collect possibly relevant info : the problem started at the time
> when "return uid" was missing. Offlineimap crashed a few times with a
> message about %d not matching None (I didn't write it down at the
> time). But now even new messages are self-duplicating ...

Yes, I do not think that the return uid thing should have any influence
on this.
> At the same point I was trying out python 2.7 - but this shouldn't
> really be relevant, should it ?
2.6 or 2.7 shouldn't make a difference, no.

> Just one question: is there a way to recompute all those UIDMapping
> data, to nuke everything and start over from scratch without
> re-downloading everything ? Apparently from what you said some time ago
> it works when syncing with a Maildir ...

It works for Maildir, as it can positively map each server mail UID to
the UID in the maildir (the maildir files store the server UID). But the
UIDMapping is the only thing connecting UIDs in the IMAP<->IMAP
case. And you would have to delete everything on one side and redownload
it, if you lost it.

(I have plans to enable recovery in the long term: by comparing the
Message-ID header and the file hash (MD5) on each side we can positively
map mails on both sides. But that will take some time to implement)

Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/offlineimap-project/attachments/20110622/22121bb1/attachment.pgp>