messages flag on sync

[Jethro Tull]

For testing my config I tried to sync the 'sent' "folder" of a gmail box to
update a copy of my actual local copy so that if it fails it doesn't mess it
up. I usually use getmail and the pop server of gmail to get new emails. As
the job was slow and there were a lot of emails I left it running and at some
point I did my usual emails check and noticed that getmail was redownloading
some messages from the 'sent' folder. These messages were those already
processed by offlineimap during its progression at the time getmail was
running. So it seems offlineimap is changing messages flag to 'new' once
processed. I was expecting a change from 'new' to 'read' to unread messages
and no change to read ones. Obviously I interrupted the process. The same
problem occurs when using offlineimap with '-q' option.

When I say "message processed" I just mean that offline imap checked it to
see whether or not it already exists locally and copy if not.

I should also mention that offlineimap actually copied all messages it found
disregarding whether or not they were already existing locally. By exploring
that folder with mutt I noticed a lot of duplicate messages appeared.

Below is a copy of my offlineimap config file:


[general]
accounts = gmail
ui = ttyui

[Account gmail]
localrepository = gmaillocal
remoterepository = gmailremote

[Repository gmaillocal]
type = Maildir
sep = '/'
##localfolders = ~/gmail
localfolders = /tmp/gmail
# nametrans...
nametrans = lambda folder: re.sub("sent", "\[Gmail\]/Sent Mail", folder)

[Repository gmailremote]
type = IMAP
remotehost = imap.gmail.com
sync_deletes = no
ssl = yes
sslcacertfile = /etc/ssl/certs/ca-certificates.crt
remoteport = 993
remoteuser = heavytull
folderfilter = lambda folder: folder in ["\[Gmail\]/Sent Mail"]
nametrans = lambda folder: re.sub("\[Gmail\]/Sent Mail", "sent", folder)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20170317/69dc70c9/attachment-0002.html>