When the IMAP server doesn't support the UIDPLUS extension so we fallback on the
internal legacy way of mapping the UID to the uploaded message (with the email
header). If the server responds with 2 UIDs offlineimap doesn't know which one
is correct and reports an error.
If for some reason all the returned UIDs are equals it's very likely fine to
map either one.
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Tested-by: https://github.com/mpsq
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/676
Reported-by Heinrich Hartmann <Heinrich@HeinrichHartmann.com>
Tested-by Heinrich Hartmann <Heinrich@HeinrichHartmann.com>
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/545
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
We use current hostname as the element of the unique file name.
Sometimes there is non-/24 zone delegation,
{{{
$ host 144.206.233.65
65.233.206.144.in-addr.arpa is an alias for 65.26/64.233.206.144.in-addr.arpa.
}}}
as per RFC 2317,
https://www.rfc-editor.org/rfc/rfc2317.txt
So on Un*x systems we may run into having path separator inside
the file name. Not good, things will choke. Prevented this
by substituting all appeared path separators in the return value.
Signed-off-by: Eygene Ryabinkin <rea@codelabs.ru>
Tested-at: my MacOSX instance, my FreeBSD instances
It was previously printing "Upgrading LocalStatus cache from version 1to version 2 for XXX"
Signed-off-by: John Ferlito <johnf@inodes.org>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
When there is not UIDPLUS we have to figure the UID by our means. When this
process fails, we don't know if the email was successfully uploaded. This patch
provides better logs to explain what happened.
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
If utf8foldernames is enabled on account level all folder names read
from the IMAP server will immediately be reencoded to UTF-8. Names
will be treated as UTF-8 as long as the IMAP server isn't contacted again,
for which they are reencoded to IMAP4-UTF-7.
This means that any further processing such as nametrans, folderfilter
etc. will act upon the UTF-8 names, which will have to be documented
carefully.
NOTE 1:
GMail repositories and folders inherit from the IMAP... classes, so I don't
know yet if these changes have ugly side-effects. But web research suggests
that GMail IMAP folders are equally encoded in UTF-7 so that should work
identically here and incorporate the same improvements.
NOTE 2:
I could not test the behaviour with idlefolders as I didn't get this option
to work at all, not even with the latest stable version.
NOTE 3:
I *did* test to sync an IMAP repository against another IMAP repository.
Signed-off-by: Urs Liska <git@ursliska.de>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
While intending *not* to change the behaviour of the existing
decodefoldernames option this commit transparently improves
the coding.
So far this worked by overriding the folder's getvisiblename() method
which reads self.visiblename from and applies the conversion on
*every* invocation of getvisiblename().
This commit does the calculation once in the IMAPFolder's __init__.
Signed-off-by: Urs Liska <git@ursliska.de>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
The support for the realdelete configuration option was removed because this
could lead to data loss.
See 51728ed to know more.
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Some returned responses end with ')' rather than 'UID XXX)' as expected.
BTW, a better policy could be to request for the 'X-OfflineIMAP' header only
rather than fetching all the headers and looking for it manually.
Also:
- Strip the output when error occurs: we don't need the full response unless
'imap' debug mode is enabled.
- Improve the comments.
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/479
Tested-by: https://github.com/secomi
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
This would require more digging to understand how this is possible. I suspect
that a previous run has been interrupted.
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/445
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
The saveall() method must acquire the lock to make writes.
Reported-and-tested-by: Julien Cubizolles <j.cubizolles@free.fr>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Allow retrying the download of messages more than twice.
Signed-off-by: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Using standard offlineimap without specific utf8 nametrans makes
offlineimap crash when generating md5 of the folder because the
foldername is already an str.
Signed-off-by: Stéphane Albert <sheeprine@oh.its.fake.nullplace.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
This should significantly improve performance when used to write large
amounts of messages.
This feature is enabled through the fsync configuration option.
Code refactorize around fsync.
This addresses #390 (although it doesn't necessarily fix all instances
of that problem yet).
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/390
Originally-written-by: Giel van Schijndel <me@mortis.eu>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
If the map file is not properly written (e.g. due to unexpected kill)
offlineimap might wrongly consider some UIDs to have been deleted from the local
side which could lead to data loss.
Use a temporary map file rather than writing to the map file directly.
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/380
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
BaseFolder now exposes an __unicode__ method so that function needing
unicode transcoding don't crash due to ascii encoding errors.
Signed-off-by: Stéphane Albert <sheeprine@oh.its.fake.nullplace.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
To further ensure that messages are synchronized strictly in UID
order, this option can be set to cause only one thread to be used
to synchronise an individual folder, though other folders may
be synchronized simultaneously by other threads.
Signed-off-by: James E. Blair <corvus@gnu.org>
Based-on-patch-by: James E. Blair <corvus@gnu.org>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Return a sorted list of UIDs in getmessageuidlist.
Some MUAs (and their users) like to display messages in UID order
(or "order received"). If offlineimap is used in IMAP<->IMAP mode,
then the order messages are received by the second IMAP server will
be different because offlineimap iterates over a UID list produced
from the keys of a dictionary, which is unsorted.
This change sorts that list of UIDs so that both IMAP servers will
have their messages in the same order (except those times where
messages are appended to folders on both repositories between
syncs).
Signed-off-by: James E. Blair <corvus@gnu.org>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
This suppressing the warning generated when running offlineimap on
python2 with -3 switch:
offlineimap/folder/Base.py:29: DeprecationWarning: Overriding __eq__
blocks inheritance of __hash__ in 3.x
Since this object is mutable it should not be hashable.
From Python documentation[1]:
A class that overrides __eq__() and does not define __hash__() will
have its __hash__() implicitly set to None.
Therefore old behaviour is preserved.
[1] https://docs.python.org/3/reference/datamodel.html
Signed-off-by: Łukasz Żarnowiecki <dolohow@outlook.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
OfflineIMAP frequently delivers mail files to the Maildir consisting exclusively
of a single ASCII digit in IDLE mode. IMAPFolder.getmessage expects 'data' to be
of the form
[(fetch-info, message-body)]
However, the imapobj.uid call in getmessage returns a list of *all* pending
untagged FETCH responses. If any message flags were changed in the selected
IMAP folder since the last command (by another client or another thread in
OfflineIMAP itself), the IMAP server will issue unsolicited FETCH responses
indicating these flag changes (RFC3501, section 7). When this happens, 'data'
will look like, for example
['1231 (FLAGS (\\Seen) UID 5300)',
'1238 (FLAGS (\\Seen) UID 5318)',
('1242 (UID 5325 BODY[] {7976}', message-body)]
Unfortunately, getmessage retrieves the message body as data[0][1], which in
this example is just the string "2", and this is what gets stored in the mail
file.
Multi-threaded OfflineIMAP with IDLE or holdconnectionopen is particularly
susceptible to this problem because flag changes synced back to the IMAP server
on one thread will appear as unsolicited FETCH responses on another thread if it
happens to have the same folder selected. This can also happen without IDLE or
holdconnectionopen or even in single-threaded OfflineIMAP with concurrent access
from other IMAP clients (webmail clients, etc.), though the window for the bug
is much smaller.
Ideally, either imaplib2 or getmessage would parse the fetch responses to find
the response for the requested UID. However, since IMAP only specifies
unilateral FETCH responses for flag changes, it's almost certainly safe to
simply find the element of 'data' that is a tuple (perhaps aborting if there is
more than one tuple) and use that.
Github-fix: https://github.com/OfflineIMAP/offlineimap/issues/162
Based-on-patch-by: Austin Clements <amdragon@MIT.EDU>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Nicolas Sebrecht
Eygene Ryabinkin
John Ferlito
Urs Liska
lkcl
Stéphane Albert
Xudong Zhang
Giel van Schijndel
James E. Blair
Łukasz Żarnowiecki
Philipp Meier
Ævar Arnfjörð Bjarmason