offlineimap does not delete messages on server

[Antonio Terceiro]

Sebastian Spaeth escreveu isso aí:
> On Mon, 16 May 2011 16:54:39 -0700, Antonio Terceiro wrote:
> > Since I upgraded to the latest version of offlineimap my INBOXes started
> > behaving weirdly, as if they were not being properly sync'ed with the IMAP
> > servers. I move all my read messages to to local folders (not handled by
> > offlineimap). But when sync again with offlineimap, those messages come back to
> > my INBOX: it seems offlineimap did not delete them on the server, or did not
> > perceived the fact that they were deleted locally.
> 
> Mmh, are you sure it only happens with the latest version? Because IMHO
> nothing has changed between 6.3.2 and 6.3.3 that could affect this. But
> I am sure you are right :-).

Yes, it only started after 6.3.3 hit Debian sid. Since I am upgrading
quite often, I am sure that before that I was using 6.3.2

> > This seems to happen only with my 'main' INBOX folders (for each account): the
> > 'INBOX.*' folders are not affected by this problem, even though they *are*
> > receiving new messages and I have tested deleting messages from them and they
> > did not come back.
> 
> Now, that sounds really, really weird. We do not treat INBOX any
> different from other folders.

ok, I was mistaken here. Is _is_ happening with other folders, it's just
that I don't delete messages from them as often as I do on INBOX'es.

> > This happens with several different IMAP servers (all my 4 IMAP accounts), and
> > I can reprodude it easily by some e-mails to myself, then syncing with
> > offlineimap, then deleting messages locally and syncing again.  It does happen
> > always, but happens frequently. When it happens, offlineimap gives warnings
> > like this:
> > 
> >   Deleting 6 messages (166, 167, 172, 173, 174, 175) in IMAP[INBOX]
> >   WARNING: Attempted to modify flags for messages [166L, 167L, 172L, 173L, 174L, 175L] in folder IMAP[INBOX], but that folder is read-only.  No flags have been modified for that message.
> 
> Right, in this case, it detected local deletions, attempts to delete the
> same messages on the IMAP server and fails because the folder claims it
> is read-only. First, we removed it from the LocalStatus cache though. So
> on the next sync, we detect the "unknown" new messages on the IMAP
> server and transfer them to the local INBOX.
> 
> AFAIK, this is the expected behavior if we fail to delete a message on
> the IMAP server. I would argue that we should not remove the message
> From LocalStatus if we fail to delete the message in the
> destination. This way, we would not retransfer the message from the IMAP
> on the next sync, but retry to delete the deleted one (which would make
> more sense). (current code snippet below)
> 
> in folder.Base.py we do on deletion:
>             for folder in [statusfolder, dstfolder]:
>                 folder.deletemessages(deletelist)
> 
> (and that should be a tad more sophisticated, checking for errors and
> doing dstfolder first)
> 
> However, the remaining puzzle and underlying cause is, "why do we think
> that INBOX is readonly" or why does the IMAP server actually tell
> so. Can you gather a debug log when it happens with -d imap -l debug.log
> and make it available (privately to me, if it contains sensitive
> stuff). Make sure to scrub out your passwords in any case.

I used the attached script (debug-626417.sh) to reproduce the problem,
which generated the attached log (offlineimap-debug.log.gz).  Some parts
of the script depend on my personal setup, but you can easily guess what
they actually do.

There is nothing sensitive in the log, since I tested with an empty
INBOX and test messages sent from/to myself. I did wiped by password
from it.

-- 
Antonio Terceiro <terceiro at softwarelivre.org>
http://softwarelivre.org/terceiro


-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug-626417.sh
Type: application/x-sh
Size: 896 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110517/6f803b40/attachment-0003.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: offlineimap-debug.log.gz
Type: application/octet-stream
Size: 30471 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110517/6f803b40/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110517/6f803b40/attachment-0001.sig>