Weird recopying behavior with 6.4.2 and mutt maildir

[Zak Smith]

I've been using offlineimap for many years, up until recently I was
several versions behind the head of development, 5.99.x.    I just
upgraded to 6.4.2 and noticed some weird behavior.   I am using mutt
1.5.20 on ubuntu 10.10.

When I "save" messages from my Inbox to the "received" folder (ie,
delete from INBOX and insert into received), the first time I run
offlineimap, it does this:

* On the remote side, deletes the messages from INBOX

* copies the messages from local to remote in the received folder

However, when I do this on more than one message at a time, on N-1 of
them, the SECOND time I run offlineimap (with no other events
happening remote or local), it copies them BACK to local from the
remote.

When mutt moves files into a new maildir, it sets up filenames that
look like this:
recvd-pending/cur/1325131833.21835_1.zim:2,S
and offlineimap's look like this:
recvd-pending/cur/1325131869_0.21938.zim,U=49481,FMD5=ae41a48a3b6f9d3f721d8d605a1d251f:2,S

When it does the copy-to-remote-then-copy-back, it effectively moves
the mail from the mutt filename to the offlineimap filename and as far
as I can tell no messages are actually duplicated or deleted --
however, it copies the message BACK to local when it originated
locally (and there was no change on the remote side).

The weird thing is, the number of messages that are copied "back" on
the second run of offlineimap is always one less than the number that
were synced the first time.

Here's a series of diffs between a "find ." in my Mail directory that
illustrates the name changes of the files:

$ diff snap3 snap4
481d480
< INBOX/cur/1325131670_1.21290.zim,U=174823,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
531a531
> recvd-pending/cur/1325131833.21835_1.zim:2,S

^ mutt moved mail from inbox to recvd-pending. After this I ran an offlineimap and it copied the message to the server.



$ diff snap4 snap5
522a523
> recvd-pending/cur/1325131869_0.21938.zim,U=49481,FMD5=ae41a48a3b6f9d3f721d8d605a1d251f:2,S
531d531
< recvd-pending/cur/1325131833.21835_1.zim:2,S

^ this is the result after I ran offlineimap AGAIN and it copied it back again



Here are output snippets representative of the case:

Establishing connection to
Syncing INBOX: IMAP -> Maildir
Deleting 2 messages (174824:174825) in IMAP[INBOX]
Syncing INBOX.recvd-pending: IMAP -> Maildir
Copy message -2 (1 of 2) Local:recvd-pending -> DemigodInbox
Copy message -1 (2 of 2) Local:recvd-pending -> DemigodInbox
Skipping INBOX.sent-pending (not changed)
*** Finished account 'Inbox' in 0:02


Establishing connection to 
Skipping INBOX (not changed)
Syncing INBOX.recvd-pending: IMAP -> Maildir
Copy message 49486 (1 of 1) DemigodInbox:INBOX.recvd-pending -> Local
Skipping INBOX.sent-pending (not changed)
*** Finished account 'Inbox' in 0:01


I am quite sure this did not happen on versions before 6, and I just noticed this cropping up when I was examining the logs today,  

Offlineimap clearly is doing some filename changes in the maildir directories, but it seems like in some cases it's getting a little confused and having to copy down from the server changes AGAIN changes that originated locally.


any ideas?

thanks
Zak








--
# Zak Smith    mobile 970-232-4468    zak at computer.org