Sebastian Spaeth wrote on Thu, Jan 19, 2012 at 10:28:19 +0100:
> Forgot to Cc the list...
>
> On Wed, 18 Jan 2012 08:17:44 +0200, Daniel Shahaf wrote:
> > Sebastian Spaeth wrote on Wed, Jan 18, 2012 at 01:02:22 +0100:
> >> http://docs.offlineimap.org
> >
> > I've subscribed. And if you tell me where the sources for docs.o.o are,
> > I'll send a patch for them, too. :-)
>
> They are autogenerated from docs/dev-docs-src, and
> docs/[INSTALL|MANUAL|FAQ].rst respectively. Patches are welcome...
>
> Sebastian
From 84fcb9fa5de9eb2f95d588a7403d9c6d13f0c7f0 Mon Sep 17 00:00:00 2001
From: Daniel Shahaf <d.s@daniel.shahaf.name>
Date: Thu, 19 Jan 2012 11:53:13 +0200
Subject: [PATCH] Document the commits@ list
Mention the commits@ list in SubmittingPatches.rst.
Mention SubmittingPatches.rst in the API part of the documentation.
Signed-off-by: Daniel Shahaf <d.s@daniel.shahaf.name>
Rename getuidvalidity -> get_uidvalidity and cache the IMAP result.
1) Start modernizing our function names using more underscores
2) IMAPs implementation of get_uidvalidity was removing the UIDVALIDITY result
from the imaplib2 result stack, so subsequent calls would return "None".
As various functions can invoke this, this led to some errors that we
avoid by caching the current UIDVALIDITY value in the Folder instance.
There are more simplifications and improvements to be made.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Rename getuidvalidity -> get_uidvalidity and cache the IMAP result.
1) Start modernizing our function names using more underscores
2) IMAPs implementation of get_uidvalidity was removing the UIDVALIDITY result
from the imaplib2 result stack, so subsequent calls would return "None".
As various functions can invoke this, this led to some errors that we
avoid by caching the current UIDVALIDITY value in the Folder instance.
There are more simplifications and improvements to be made.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Don't create the temp dirs in the current directory, but create them in
the same directory as the credentials.conf file is. We still need to
prevent deleting them on test failure, so that they can be inspected
manually.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
"python setup.py test" will now run the complete test suite. Remove the
previous ./test command.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
To run the test suite from the main setup.py we need to be able to
import and run the test suite from a different folder than the "test"
dir.
Make "test" a package and fix the imports to still work when imported
from another folder.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
This is the first revision that actually performs a test, in that it
starts up OfflineImap and sees if there are any exceptions.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
commit f2a94af5 introduced the use of time.sleep in ui/TTY.py without
importing it. This caused a regression in 6.5.2, crashing OfflineIMap
when in refresh mode.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
We were using super() on a class derived from logging.Formatter() which
worked fine in python 2.7. Apparently python 2.6 uses old-style classes
for this, so the TTYUI broke and crashed OfflineImap. This was
introduced in OLI 6.5.0, I think.
Fix it by calling logging.Formatter.... directly, rather than the
elegant super() (which I happen to like a lot more than is appropriate
in the python world).
Reported by Nik Reiman as github issue 23, should fix that issue.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
commit f2a94af5 introduced the use of time.sleep in ui/TTY.py without
importing it. This caused a regression in 6.5.2, crashing OfflineIMap
when in refresh mode.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
We were using super() on a class derived from logging.Formatter() which
worked fine in python 2.7. Apparently python 2.6 uses old-style classes
for this, so the TTYUI broke and crashed OfflineImap. This was
introduced in OLI 6.5.0, I think.
Fix it by calling logging.Formatter.... directly, rather than the
elegant super() (which I happen to like a lot more than is appropriate
in the python world).
Reported by Nik Reiman as github issue 23, should fix that issue.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
When deleting many (eg 2000) mails using the SQLITE backend, this takes
a long time durig which OfflineImap can not be aborted via
CTRL-C. Thinking it had frozen permanently, I killed it hard, leaving a
corrupted db journal (which leads to awkwards complaints by OLI on
subsequent starts!). That shows that delete performance is critical and
needs improvement.
We were iterating through the list of messages to delete and deleted
them one-by-one execute()'ing a new SQL Query for each message. This
patch improves the situation by allowing us to use executemany(), which
is -despite still being one SQL query per message- much faster. This is
because rather than performing a commit() after each mail, we now do
only one commit() after all mails have been deleted.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Improve wording, and integrate the MANUAL and INSTALL and FAQ documents
into our complete user manual that is hosted online.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
OfflineIMAP v6.5.2-rc1 (2012-01-09)
===================================
Commits v6.5.1.1 - v6.5.2-rc1:
note: Proper Changelog still in Changelog-draft.rst
d72bb88 Improve error message
3284e01 Revert "use .response() rather _get_untagged_response()"
81f194a mbnames should write out local and not nametransformed box names
7184ec2 Sanity check return value of UIDVALIDTY response
50de217 Allow to pass 'force' arg to selectro() to enforce a new select
ed71805 Changelog entry about "realdelete" option
0a275b9 Add scary warnings about "realdelete" option
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Recently the internal function use of imaplib2's _get_untagged_response()
was switched to use the public documented .response() function (which
should return the same data). However within a few fays we received reports
that both uses of a) the UIDVALIDITY fetching and b) the APPENDUID fetching
returned [None] as data although the IMAP log definitely shows that data
was returned. Revert to using the undocumented internal imaplib2 function,
that seemed to have worked without problems. This needs to be taken up to
the imaplib2 developer.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Rather than to write out the nametrans'lated folder names for mbnames,
we now write out the local untransformed box names. This is generally
what we want. This became relevant since we support nametrans rules on
the local side since only a short time. Reported by Paul Collignan.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
We have a reported case where response('UIDVALIDITY') returned [None]
which results in an ugly non-intuitive crash. Sanity check and report
something nicer.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Pass through the 'force' argument from selectro() to select() so that it
can also enforce a new SELECT even if we already are on that folder.
Also change the default parameter from '0' to 'False' to make clear that
this is a Bool.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
WARNING: I consider the Gmail "realdelete" option as harmful with the
potential for DATALOSS. Add scary warnings to offlineimap.conf.
See the analysis at
http://article.gmane.org/gmane.mail.imap.offlineimap.general/5265
Deleting a message from a Gmail folder via the IMAP interface will just
remove that folder's label from the message: the message will continue
to exist in the '[Gmail]/All Mail' folder. If `realdelete` is set to
`True`, then deleted messages will be moved to the '[Gmail]/Trash'
folder. BEWARE: this will immediately delete a messages from *all
folders* it belongs to!
AS OFFLINEIMAP IMPLEMENTS FOLDER MOVES AS 1) AN ADD and 2) A DELETE (the
order can vary), THIS MEANS THAT A FOLDER MOVE CAN CAUSE DATALOSS. DO
NOT USE IT AND MOVE MAIL TO "[Gmail]/Trash" TO DELETE MAIL FROM
"[Gmail]/All Mail"!
We will need to discuss whether to completely disable that feature.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
WARNING: I consider the Gmail "realdelete" option as harmful with the
potential for DATALOSS. Add scary warnings to offlineimap.conf.
See the analysis at
http://article.gmane.org/gmane.mail.imap.offlineimap.general/5265
Deleting a message from a Gmail folder via the IMAP interface will just
remove that folder's label from the message: the message will continue
to exist in the '[Gmail]/All Mail' folder. If `realdelete` is set to
`True`, then deleted messages will be moved to the '[Gmail]/Trash'
folder. BEWARE: this will immediately delete a messages from *all
folders* it belongs to!
AS OFFLINEIMAP IMPLEMENTS FOLDER MOVES AS 1) AN ADD and 2) A DELETE (the
order can vary), THIS MEANS THAT A FOLDER MOVE CAN CAUSE DATALOSS. DO
NOT USE IT AND MOVE MAIL TO "[Gmail]/Trash" TO DELETE MAIL FROM
"[Gmail]/All Mail"!
We will need to discuss whether to completely disable that feature.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Add a changelog to W. Trevor King's previous commit. Also make wording a
bit more consistent and and remove a now unneeded comparison (dirname is
always set when extension is set).
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
On Tue, Dec 13, 2011 at 12:00:57PM -0500, W. Trevor King wrote:
> I've attached a patch that does fix the problem…
Oops, *now* I've attached the patch and logs ;).
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
From 3067b1b4dfb00d165bd9480ea49f446adb12991d Mon Sep 17 00:00:00 2001
From: W. Trevor King <wking@drexel.edu>
Date: Tue, 13 Dec 2011 11:26:00 -0500
Subject: [PATCH] Only scan children in _getfolders_scandir if extension is set.
When sep is '/', MaildirRepository._getfolders_scandir recursively
checks sub-directories for additional maildirs. The old loop logic
always checked the top directory and its children. This lead to
children being found twice, once from their parent, with dirname
matching their directory name, and once from themselves, with a
dirname of ''.
This patch fixes the problem by only checking the top directory when
extension is not set (i.e. for the root directory).
Do not read in custom maildir flags, or we would try to sync them over
the wire. The next step will be to merge flag writes with existing
custom flags, so we don't lose information.
The long term goal will be to attempt to sync flags to the other side,
of course.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
