patch from Mike Gerber
Two times today I have found my offlineimap to have died with this same
situation. It appears as if certain types of messages (both spam in my
situation), cause offlineimap to choke. When it does it cannot proceed.
This means that when I run offlineimap, it pulls in messages from some
folders, then it hits the folder with the bad message and dies, leaving
undownloaded mail on the server. The only fix to this problem is to find
the problem message on the server and remove it by hand. This isn't such
a huge deal for me, since I run the server, but other people have to
come to me to ask me to delete these messages, and until I do they
cannot download their email.
I have captured the output by running script during one of these
incidents, this has been attached. Additionally, I have also attach the
problematic message.
The patch seems to work for me, might need some Python wizard and better
testing, though.
fixes deb#396443
r[1] is a list. In case it contains more than one 'str' they are concatenated
using '. '. In processmessagesflags the join is tested, for savemessagesflags I
assume that it is also needed.
I have tested this and Dovecot no longer beats offlineimap
to the punch. (-:
I achieved that by keeping the renames in tmp/ until it finally does
one last rename in new/ or cur/.
fsync the Maildir file, its final directory when writing a new message.
fsync the localstatus file and its final directory when writing the
local status cache.
This should reduce duplication in the event of hardware trouble.
fixes#8
see thread at http://lists.complete.org/offlineimap@complete.org/2007/03/threads.html.gz
* Reduced the number of parameters passed to ui.validityproblem() because they were all just method-calls to the folder object, which is already passed as the first parameter (reduction of unnecessary complexity).
* Improved the diagnostic message for an 'UID validity problem' by including the name of the repository in which the folder resides; previously it was not possible to determine from the diagnostic alone on which side the problem was.
* Reduced the number of parameters passed to ui.validityproblem() because they were all just method-calls to the folder object, which is already passed as the first parameter (reduction of unnecessary complexity).
From: Peter Colberg
Hello,
using offlineimap with the preauthtunnel option to start a remote
IMAP daemon via ssh, a zombie process is left behind during the
autorefresh sleep period if not holding the connection open.
Above behaviour is a result of using os.popen2 to spawn the tunnel
process, which makes it impossible waiting for the child process
to terminate when shutting down the tunnel.
The patch included below fixes the issue by employing the Popen
class from the subprocess module, which seems to be the preferred
way to spawn processes and connect to their pipes in any case (at
least since python version 2.4.4, which fixes a memory leak in the
subprocess module).
Regards,
Peter
fixes deb#410730
From: Mark Brown <broonie@sirena.org.uk>
Currently offlineimap will attempt to connect to the first address
returned by addrinfo() for the remote system and will fail if that fails
even if another result would have worked. This is particularly common
when the remote system supports both IPv4 and IPv6 - a laptop may in
some environments have no routable IPv6 connectivity so if the IPv6
address is returned first the connect will fail even though IPv4 would
have worked.
This is actually a bug in imaplib, a copy of which is included in
offlineimap. This patch fixes the problem by looping over all the
results returned by getaddrinfo(). Unfortunately it mangles the error
reporting slightly since I couldn't work out how to raise an appropriate
exception, though given that that that was a Python backtrace there was
work to do there anyway.
Note that I have only tested the SSL case.
It looks like I accidentally recorded the wrong version of Curses.py --
originally this code was there, but I moved it over to UIBase so it would
cover the TTY UI also.
