Mess with Trash

[Sebastian Spaeth]

On Sat, 12 Mar 2011 10:42:48 +0300, Ivan Semin <ivun at wirebyte.com> wrote:
> A  couple  of offtopic words first. Thanks for all the recent fixes, I
> am  looking  forward  for  the  new  version  to  try  all that stuff,
> hopefully that will resolve all the gmail issues I am having too.

Hi there, I am sure offlineimap will become more robust over time. I am
not sure any changes so far will help you with gmail. I know that *I*
haven't focused on gmail. It's server implementation is a bitch.

Could it be that you are seeing
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481041
 
Symptoms are that if you locally delete mails, they *seem* to be
correctly deleted on the gmail side, but on subsequent runs are
re-downloaded?

> Now  my  new problem. Just reminding, I am syncing 8 gmail accounts to
> local dovecot accounts (to avoid gmail banning me for bandwidth limit,
> as we have up to 10 people working with each account simultaneously).
> I have the following in config:
> 
> type = Gmail
> remotehost = imap.gmail.com
> remoteport = 993
> ssl = yes
Above 3 lines are not needed as set automatically. Just FYI.

> realdelete = no
> nametrans = lambda folder: re.sub('.*Trash$', 'Trash', folder)

You don't have an "INOBX." prefix or something?
> folderfilter = lambda foldername: foldername not in ['[Gmail]/All
> Mail','[Gmail]/Sent Messages','[Gmail]/Starred']
> 
> The  nametrans  line  is to make Thunderbird (a mail client) delete to
> the same folder as gmail.

OK, another theory. What I am sure about is that this occurs because
Gmail IS NOT AN IMAP SERVER, even if they like to call it this way!

You have realdelete=no. That means that if you delete something in
Thunderbird, it will likely "expunge" it from the folder the message was
in and put it into the local Trash folder.

However, when you "expunge" on the Gmail server with "realdelete=no", it
will merely remove the folder label on the google side and not really
delete the message. (is that really what you want to achieve with
realdelete=no?). I am not sure if it will put it into a Trash folder on
the Google side.

This behavior makes it very tricky to achieve proper IMAP syncing. IMAP
server have flags, so I am not sure why Google chose the approach it did
(perhaps because mail clients deal nicely with folders but only have
limited support for flags...).

Anyway, before I start rambling. Can you try the latest "next" branch
and see if you still see that behavior?
https://github.com/nicolas33/offlineimap/tarball/next

It contains a slight change in the syncing strategy, and if my hunch is
right (which I have not been very good at in articulating it,
sorry). Your behavior might not occur there.

That having said, the whole gmail support thing is still something I am
not very familiar with. It's a pity that it is so popular :-).

> Syncing Sent Messages: Gmail -> MappedIMAP
> Syncing Trash: Gmail -> MappedIMAP
> Deleting 143 messages in MappedIMAP[Trash]
...
> Copy message 1 Gmail[Trash] -> MappedIMAP[Trash]
...
> Copy message 11 Gmail[Trash] -> MappedIMAP[Trash]
> Syncing [Gmail]/Trash: Gmail -> MappedIMAP
> Deleting 11 messages (1,...,11) in MappedIMAP[Trash]
...
> Copy message 3153 Gmail[[Gmail]/Trash] -> MappedIMAP[Trash], LocalStatus[Trash]
...

Fun, so we delete 143 msg on LOCAL, then copy over 11 messages from
GMAIL to LOCAL, then delete 11 messages on LOCAL then copy over 143 msg
From GMAIL TO LOCAL? ??? No wonder you exceed bandwidth. GMail's IMAP is
a pain, but this should never happen in any case.

Do try recent 'next' and tell me if you see a different behavior. I
might also need a more verbose log, if you are still seeing this.

Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110312/233f2145/attachment-0001.sig>