2002-06-19 08:08:59 +02:00
|
|
|
# Maildir folder support
|
2015-01-01 21:41:11 +01:00
|
|
|
# Copyright (C) 2002-2015 John Goerzen & contributors
|
2002-06-19 07:55:12 +02:00
|
|
|
#
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
2003-04-16 21:23:45 +02:00
|
|
|
# the Free Software Foundation; either version 2 of the License, or
|
|
|
|
# (at your option) any later version.
|
2002-06-19 07:55:12 +02:00
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program; if not, write to the Free Software
|
2006-08-12 06:15:55 +02:00
|
|
|
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
2002-06-19 07:55:12 +02:00
|
|
|
|
2011-03-11 22:13:21 +01:00
|
|
|
import socket
|
|
|
|
import time
|
|
|
|
import re
|
|
|
|
import os
|
2015-01-11 21:44:24 +01:00
|
|
|
from sys import exc_info
|
2012-02-05 12:52:12 +01:00
|
|
|
from .Base import BaseFolder
|
2003-05-06 21:26:12 +02:00
|
|
|
from threading import Lock
|
2008-12-04 22:45:15 +01:00
|
|
|
try:
|
|
|
|
from hashlib import md5
|
|
|
|
except ImportError:
|
2008-12-24 19:22:10 +01:00
|
|
|
from md5 import md5
|
2011-08-16 12:16:46 +02:00
|
|
|
try: # python 2.6 has set() built in
|
|
|
|
set
|
|
|
|
except NameError:
|
|
|
|
from sets import Set as set
|
|
|
|
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
from offlineimap import OfflineImapError, emailutil
|
2011-06-13 15:22:37 +02:00
|
|
|
|
2011-08-30 11:01:49 +02:00
|
|
|
# Find the UID in a message filename
|
|
|
|
re_uidmatch = re.compile(',U=(\d+)')
|
|
|
|
# Find a numeric timestamp in a string (filename prefix)
|
|
|
|
re_timestampmatch = re.compile('(\d+)');
|
2002-07-23 21:55:18 +02:00
|
|
|
|
2002-06-22 06:32:29 +02:00
|
|
|
timeseq = 0
|
2012-02-05 13:28:00 +01:00
|
|
|
lasttime = 0
|
2003-05-06 21:26:12 +02:00
|
|
|
timelock = Lock()
|
2002-06-22 06:32:29 +02:00
|
|
|
|
2014-03-16 13:27:35 +01:00
|
|
|
def _gettimeseq():
|
2003-05-06 21:26:12 +02:00
|
|
|
global lasttime, timeseq, timelock
|
|
|
|
timelock.acquire()
|
|
|
|
try:
|
|
|
|
thistime = long(time.time())
|
|
|
|
if thistime == lasttime:
|
|
|
|
timeseq += 1
|
|
|
|
return (thistime, timeseq)
|
|
|
|
else:
|
|
|
|
lasttime = thistime
|
|
|
|
timeseq = 0
|
|
|
|
return (thistime, timeseq)
|
|
|
|
finally:
|
|
|
|
timelock.release()
|
2002-06-19 07:55:12 +02:00
|
|
|
|
2002-06-19 08:08:59 +02:00
|
|
|
class MaildirFolder(BaseFolder):
|
2011-09-16 10:54:24 +02:00
|
|
|
def __init__(self, root, name, sep, repository):
|
2011-09-30 17:20:11 +02:00
|
|
|
self.sep = sep # needs to be set before super().__init__
|
2011-09-16 10:54:22 +02:00
|
|
|
super(MaildirFolder, self).__init__(name, repository)
|
2011-09-16 10:54:24 +02:00
|
|
|
self.dofsync = self.config.getdefaultboolean("general", "fsync", True)
|
2002-06-19 08:08:59 +02:00
|
|
|
self.root = root
|
2015-02-13 17:02:33 +01:00
|
|
|
self.messagelist = {}
|
2012-01-06 13:05:08 +01:00
|
|
|
# check if we should use a different infosep to support Win file systems
|
2011-07-12 09:34:02 +02:00
|
|
|
self.wincompatible = self.config.getdefaultboolean(
|
|
|
|
"Account "+self.accountname, "maildir-windows-compatible", False)
|
2011-08-30 11:01:17 +02:00
|
|
|
self.infosep = '!' if self.wincompatible else ':'
|
|
|
|
"""infosep is the separator between maildir name and flag appendix"""
|
2015-01-14 22:58:25 +01:00
|
|
|
self.re_flagmatch = re.compile('%s2,(\w*)'% self.infosep)
|
2011-01-05 17:00:57 +01:00
|
|
|
#self.ui is set in BaseFolder.init()
|
2011-08-30 11:01:49 +02:00
|
|
|
# Everything up to the first comma or colon (or ! if Windows):
|
|
|
|
self.re_prefixmatch = re.compile('([^'+ self.infosep + ',]*)')
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
# folder's md, so we can match with recorded file md5 for validity.
|
2011-08-30 11:01:49 +02:00
|
|
|
self._foldermd5 = md5(self.getvisiblename()).hexdigest()
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
# Cache the full folder path, as we use getfullname() very often.
|
2011-06-10 17:32:39 +02:00
|
|
|
self._fullname = os.path.join(self.getroot(), self.getname())
|
2003-01-06 00:07:58 +01:00
|
|
|
|
2014-03-16 13:27:35 +01:00
|
|
|
# Interface from BaseFolder
|
2002-06-20 07:14:35 +02:00
|
|
|
def getfullname(self):
|
2011-06-10 17:32:39 +02:00
|
|
|
"""Return the absolute file path to the Maildir folder (sans cur|new)"""
|
|
|
|
return self._fullname
|
2002-06-20 07:14:35 +02:00
|
|
|
|
2014-03-16 13:27:35 +01:00
|
|
|
# Interface from BaseFolder
|
2012-01-19 11:24:16 +01:00
|
|
|
def get_uidvalidity(self):
|
|
|
|
"""Retrieve the current connections UIDVALIDITY value
|
|
|
|
|
|
|
|
Maildirs have no notion of uidvalidity, so we just return a magic
|
2003-04-18 04:18:34 +02:00
|
|
|
token."""
|
|
|
|
return 42
|
2002-06-20 05:33:23 +02:00
|
|
|
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
# Checks to see if the given message is within the maximum age according
|
|
|
|
# to the maildir name which should begin with a timestamp
|
2009-08-16 14:42:39 +02:00
|
|
|
def _iswithinmaxage(self, messagename, maxage):
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
# In order to have the same behaviour as SINCE in an IMAP search
|
|
|
|
# we must convert this to the oldest time and then strip off hrs/mins
|
|
|
|
# from that day.
|
2009-08-16 14:42:39 +02:00
|
|
|
oldest_time_utc = time.time() - (60*60*24*maxage)
|
|
|
|
oldest_time_struct = time.gmtime(oldest_time_utc)
|
|
|
|
oldest_time_today_seconds = ((oldest_time_struct[3] * 3600) \
|
|
|
|
+ (oldest_time_struct[4] * 60) \
|
|
|
|
+ oldest_time_struct[5])
|
|
|
|
oldest_time_utc -= oldest_time_today_seconds
|
|
|
|
|
2011-08-30 11:01:49 +02:00
|
|
|
timestampmatch = re_timestampmatch.search(messagename)
|
2013-08-27 13:57:55 +02:00
|
|
|
if not timestampmatch:
|
|
|
|
return True
|
2009-08-16 14:42:39 +02:00
|
|
|
timestampstr = timestampmatch.group()
|
|
|
|
timestamplong = long(timestampstr)
|
|
|
|
if(timestamplong < oldest_time_utc):
|
|
|
|
return False
|
|
|
|
else:
|
|
|
|
return True
|
|
|
|
|
2011-08-30 11:01:49 +02:00
|
|
|
def _parse_filename(self, filename):
|
|
|
|
"""Returns a messages file name components
|
|
|
|
|
|
|
|
Receives the file name (without path) of a msg. Usual format is
|
|
|
|
'<%d_%d.%d.%s>,U=<%d>,FMD5=<%s>:2,<FLAGS>' (pointy brackets
|
|
|
|
denoting the various components).
|
|
|
|
|
|
|
|
If FMD5 does not correspond with the current folder MD5, we will
|
|
|
|
return None for the UID & FMD5 (as it is not valid in this
|
|
|
|
folder). If UID or FMD5 can not be detected, we return `None`
|
|
|
|
for the respective element. If flags are empty or cannot be
|
|
|
|
detected, we return an empty flags list.
|
|
|
|
|
|
|
|
:returns: (prefix, UID, FMD5, flags). UID is a numeric "long"
|
2015-01-14 22:58:25 +01:00
|
|
|
type. flags is a set() of Maildir flags.
|
|
|
|
"""
|
2015-01-01 21:41:11 +01:00
|
|
|
|
2011-08-30 11:01:49 +02:00
|
|
|
prefix, uid, fmd5, flags = None, None, None, set()
|
|
|
|
prefixmatch = self.re_prefixmatch.match(filename)
|
|
|
|
if prefixmatch:
|
|
|
|
prefix = prefixmatch.group(1)
|
2015-01-14 22:58:25 +01:00
|
|
|
folderstr = ',FMD5=%s'% self._foldermd5
|
2011-08-30 11:01:49 +02:00
|
|
|
foldermatch = folderstr in filename
|
|
|
|
# If there was no folder MD5 specified, or if it mismatches,
|
|
|
|
# assume it is a foreign (new) message and ret: uid, fmd5 = None, None
|
|
|
|
if foldermatch:
|
|
|
|
uidmatch = re_uidmatch.search(filename)
|
|
|
|
if uidmatch:
|
|
|
|
uid = long(uidmatch.group(1))
|
|
|
|
flagmatch = self.re_flagmatch.search(filename)
|
|
|
|
if flagmatch:
|
2012-01-07 22:00:45 +01:00
|
|
|
# Filter out all lowercase (custom maildir) flags. We don't
|
|
|
|
# handle them yet.
|
|
|
|
flags = set((c for c in flagmatch.group(1) if not c.islower()))
|
2011-08-30 11:01:49 +02:00
|
|
|
return prefix, uid, fmd5, flags
|
2009-08-16 14:42:39 +02:00
|
|
|
|
2002-07-16 04:26:58 +02:00
|
|
|
def _scanfolder(self):
|
2011-08-30 11:01:49 +02:00
|
|
|
"""Cache the message list from a Maildir.
|
|
|
|
|
|
|
|
Maildir flags are: R (replied) S (seen) T (trashed) D (draft) F
|
|
|
|
(flagged).
|
2015-01-14 22:58:25 +01:00
|
|
|
:returns: dict that can be used as self.messagelist.
|
|
|
|
"""
|
|
|
|
|
2011-08-30 11:01:49 +02:00
|
|
|
maxage = self.config.getdefaultint("Account " + self.accountname,
|
|
|
|
"maxage", None)
|
|
|
|
maxsize = self.config.getdefaultint("Account " + self.accountname,
|
|
|
|
"maxsize", None)
|
2002-07-16 04:26:58 +02:00
|
|
|
retval = {}
|
2002-06-20 05:33:23 +02:00
|
|
|
files = []
|
2011-08-30 11:01:49 +02:00
|
|
|
nouidcounter = -1 # Messages without UIDs get negative UIDs.
|
2002-06-20 05:33:23 +02:00
|
|
|
for dirannex in ['new', 'cur']:
|
|
|
|
fulldirname = os.path.join(self.getfullname(), dirannex)
|
2011-08-30 11:01:49 +02:00
|
|
|
files.extend((dirannex, filename) for
|
2009-07-07 07:52:00 +02:00
|
|
|
filename in os.listdir(fulldirname))
|
2011-08-30 11:01:49 +02:00
|
|
|
|
|
|
|
for dirannex, filename in files:
|
|
|
|
# We store just dirannex and filename, ie 'cur/123...'
|
|
|
|
filepath = os.path.join(dirannex, filename)
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
# Check maxage/maxsize if this message should be considered.
|
2011-08-30 11:01:49 +02:00
|
|
|
if maxage and not self._iswithinmaxage(filename, maxage):
|
|
|
|
continue
|
|
|
|
if maxsize and (os.path.getsize(os.path.join(
|
|
|
|
self.getfullname(), filepath)) > maxsize):
|
|
|
|
continue
|
|
|
|
|
|
|
|
(prefix, uid, fmd5, flags) = self._parse_filename(filename)
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
if uid is None: # Assign negative uid to upload it.
|
2002-06-20 06:14:54 +02:00
|
|
|
uid = nouidcounter
|
2002-06-22 06:39:02 +02:00
|
|
|
nouidcounter -= 1
|
2002-06-22 06:32:29 +02:00
|
|
|
else: # It comes from our folder.
|
2011-08-30 11:01:49 +02:00
|
|
|
uidmatch = re_uidmatch.search(filename)
|
2002-06-22 06:32:29 +02:00
|
|
|
uid = None
|
|
|
|
if not uidmatch:
|
|
|
|
uid = nouidcounter
|
|
|
|
nouidcounter -= 1
|
|
|
|
else:
|
|
|
|
uid = long(uidmatch.group(1))
|
2011-08-30 11:19:53 +02:00
|
|
|
# 'filename' is 'dirannex/filename', e.g. cur/123,U=1,FMD5=1:2,S
|
2014-08-03 14:47:26 +02:00
|
|
|
retval[uid] = self.msglist_item_initializer(uid)
|
|
|
|
retval[uid]['flags'] = flags
|
|
|
|
retval[uid]['filename'] = filepath
|
2002-07-16 04:26:58 +02:00
|
|
|
return retval
|
|
|
|
|
2014-03-16 13:27:35 +01:00
|
|
|
# Interface from BaseFolder
|
Daniel Jacobowitz patches
fixes deb#433732
Date: Sun, 30 Sep 2007 13:54:56 -0400
From: Daniel Jacobowitz <drow@false.org>
To: offlineimap@complete.org
Subject: Assorted patches
Here's the result of a lazy Sunday hacking on offlineimap. Sorry for
not breaking this into multiple patches. They're mostly logically
independent so just ask if that would make a difference.
First, a new -q (quick) option. The quick option means to only update
folders that seem to have had significant changes. For Maildir, any
change to any message UID or flags is significant, because checking
the flags doesn't add a significant cost. For IMAP, only a change to
the total number of messages or a change in the UID of the most recent
message is significant. This should catch everything except for
flags changes.
The difference in bandwidth is astonishing: a quick sync takes 80K
instead of 5.3MB, and 28 seconds instead of 90.
There's a configuration variable that lets you say every tenth sync
should update flags, but let all the intervening ones be lighter.
Second, a fix to the UID validity problems many people have been
reporting with Courier. As discussed in Debian bug #433732, I changed
the UID validity check to use SELECT unless the server complains that
the folder is read-only. This avoids the Courier bug (see the Debian
log for more details). This won't fix existing validity errors, you
need to remove the local status and validity files by hand and resync.
Third, some speedups in Maildir checking. It's still pretty slow
due to a combination of poor performance in os.listdir (never reads
more than 4K of directory entries at a time) and some semaphore that
leads to lots of futex wake operations, but at least this saves
20% or so of the CPU time running offlineimap on a single folder:
Time with quick refresh and md5 in loop: 4.75s user 0.46s system 12%
cpu 41.751 total
Time with quick refresh and md5 out of loop: 4.38s user 0.50s system
14% cpu 34.799 total
Time using string compare to check folder: 4.11s user 0.47s system 13%
cpu 34.788 total
And fourth, some display fixes for Curses.Blinkenlights. I made
warnings more visible, made the new quick sync message cyan, and
made all not explicitly colored messages grey. That last one was
really bugging me. Any time OfflineIMAP printed a warning in
this UI, it had even odds of coming out black on black!
Anyway, I hope these are useful. I'm happy to revise them if you see
a problem.
--
Daniel Jacobowitz
CodeSourcery
2007-10-01 23:20:37 +02:00
|
|
|
def quickchanged(self, statusfolder):
|
2011-04-11 18:09:07 +02:00
|
|
|
"""Returns True if the Maildir has changed"""
|
Daniel Jacobowitz patches
fixes deb#433732
Date: Sun, 30 Sep 2007 13:54:56 -0400
From: Daniel Jacobowitz <drow@false.org>
To: offlineimap@complete.org
Subject: Assorted patches
Here's the result of a lazy Sunday hacking on offlineimap. Sorry for
not breaking this into multiple patches. They're mostly logically
independent so just ask if that would make a difference.
First, a new -q (quick) option. The quick option means to only update
folders that seem to have had significant changes. For Maildir, any
change to any message UID or flags is significant, because checking
the flags doesn't add a significant cost. For IMAP, only a change to
the total number of messages or a change in the UID of the most recent
message is significant. This should catch everything except for
flags changes.
The difference in bandwidth is astonishing: a quick sync takes 80K
instead of 5.3MB, and 28 seconds instead of 90.
There's a configuration variable that lets you say every tenth sync
should update flags, but let all the intervening ones be lighter.
Second, a fix to the UID validity problems many people have been
reporting with Courier. As discussed in Debian bug #433732, I changed
the UID validity check to use SELECT unless the server complains that
the folder is read-only. This avoids the Courier bug (see the Debian
log for more details). This won't fix existing validity errors, you
need to remove the local status and validity files by hand and resync.
Third, some speedups in Maildir checking. It's still pretty slow
due to a combination of poor performance in os.listdir (never reads
more than 4K of directory entries at a time) and some semaphore that
leads to lots of futex wake operations, but at least this saves
20% or so of the CPU time running offlineimap on a single folder:
Time with quick refresh and md5 in loop: 4.75s user 0.46s system 12%
cpu 41.751 total
Time with quick refresh and md5 out of loop: 4.38s user 0.50s system
14% cpu 34.799 total
Time using string compare to check folder: 4.11s user 0.47s system 13%
cpu 34.788 total
And fourth, some display fixes for Curses.Blinkenlights. I made
warnings more visible, made the new quick sync message cyan, and
made all not explicitly colored messages grey. That last one was
really bugging me. Any time OfflineIMAP printed a warning in
this UI, it had even odds of coming out black on black!
Anyway, I hope these are useful. I'm happy to revise them if you see
a problem.
--
Daniel Jacobowitz
CodeSourcery
2007-10-01 23:20:37 +02:00
|
|
|
self.cachemessagelist()
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
# Folder has different uids than statusfolder => TRUE.
|
2011-04-11 18:09:07 +02:00
|
|
|
if sorted(self.getmessageuidlist()) != \
|
|
|
|
sorted(statusfolder.getmessageuidlist()):
|
Daniel Jacobowitz patches
fixes deb#433732
Date: Sun, 30 Sep 2007 13:54:56 -0400
From: Daniel Jacobowitz <drow@false.org>
To: offlineimap@complete.org
Subject: Assorted patches
Here's the result of a lazy Sunday hacking on offlineimap. Sorry for
not breaking this into multiple patches. They're mostly logically
independent so just ask if that would make a difference.
First, a new -q (quick) option. The quick option means to only update
folders that seem to have had significant changes. For Maildir, any
change to any message UID or flags is significant, because checking
the flags doesn't add a significant cost. For IMAP, only a change to
the total number of messages or a change in the UID of the most recent
message is significant. This should catch everything except for
flags changes.
The difference in bandwidth is astonishing: a quick sync takes 80K
instead of 5.3MB, and 28 seconds instead of 90.
There's a configuration variable that lets you say every tenth sync
should update flags, but let all the intervening ones be lighter.
Second, a fix to the UID validity problems many people have been
reporting with Courier. As discussed in Debian bug #433732, I changed
the UID validity check to use SELECT unless the server complains that
the folder is read-only. This avoids the Courier bug (see the Debian
log for more details). This won't fix existing validity errors, you
need to remove the local status and validity files by hand and resync.
Third, some speedups in Maildir checking. It's still pretty slow
due to a combination of poor performance in os.listdir (never reads
more than 4K of directory entries at a time) and some semaphore that
leads to lots of futex wake operations, but at least this saves
20% or so of the CPU time running offlineimap on a single folder:
Time with quick refresh and md5 in loop: 4.75s user 0.46s system 12%
cpu 41.751 total
Time with quick refresh and md5 out of loop: 4.38s user 0.50s system
14% cpu 34.799 total
Time using string compare to check folder: 4.11s user 0.47s system 13%
cpu 34.788 total
And fourth, some display fixes for Curses.Blinkenlights. I made
warnings more visible, made the new quick sync message cyan, and
made all not explicitly colored messages grey. That last one was
really bugging me. Any time OfflineIMAP printed a warning in
this UI, it had even odds of coming out black on black!
Anyway, I hope these are useful. I'm happy to revise them if you see
a problem.
--
Daniel Jacobowitz
CodeSourcery
2007-10-01 23:20:37 +02:00
|
|
|
return True
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
# Also check for flag changes, it's quick on a Maildir.
|
2011-04-11 18:09:07 +02:00
|
|
|
for (uid, message) in self.getmessagelist().iteritems():
|
|
|
|
if message['flags'] != statusfolder.getmessageflags(uid):
|
Daniel Jacobowitz patches
fixes deb#433732
Date: Sun, 30 Sep 2007 13:54:56 -0400
From: Daniel Jacobowitz <drow@false.org>
To: offlineimap@complete.org
Subject: Assorted patches
Here's the result of a lazy Sunday hacking on offlineimap. Sorry for
not breaking this into multiple patches. They're mostly logically
independent so just ask if that would make a difference.
First, a new -q (quick) option. The quick option means to only update
folders that seem to have had significant changes. For Maildir, any
change to any message UID or flags is significant, because checking
the flags doesn't add a significant cost. For IMAP, only a change to
the total number of messages or a change in the UID of the most recent
message is significant. This should catch everything except for
flags changes.
The difference in bandwidth is astonishing: a quick sync takes 80K
instead of 5.3MB, and 28 seconds instead of 90.
There's a configuration variable that lets you say every tenth sync
should update flags, but let all the intervening ones be lighter.
Second, a fix to the UID validity problems many people have been
reporting with Courier. As discussed in Debian bug #433732, I changed
the UID validity check to use SELECT unless the server complains that
the folder is read-only. This avoids the Courier bug (see the Debian
log for more details). This won't fix existing validity errors, you
need to remove the local status and validity files by hand and resync.
Third, some speedups in Maildir checking. It's still pretty slow
due to a combination of poor performance in os.listdir (never reads
more than 4K of directory entries at a time) and some semaphore that
leads to lots of futex wake operations, but at least this saves
20% or so of the CPU time running offlineimap on a single folder:
Time with quick refresh and md5 in loop: 4.75s user 0.46s system 12%
cpu 41.751 total
Time with quick refresh and md5 out of loop: 4.38s user 0.50s system
14% cpu 34.799 total
Time using string compare to check folder: 4.11s user 0.47s system 13%
cpu 34.788 total
And fourth, some display fixes for Curses.Blinkenlights. I made
warnings more visible, made the new quick sync message cyan, and
made all not explicitly colored messages grey. That last one was
really bugging me. Any time OfflineIMAP printed a warning in
this UI, it had even odds of coming out black on black!
Anyway, I hope these are useful. I'm happy to revise them if you see
a problem.
--
Daniel Jacobowitz
CodeSourcery
2007-10-01 23:20:37 +02:00
|
|
|
return True
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
return False # Nope, nothing changed.
|
Daniel Jacobowitz patches
fixes deb#433732
Date: Sun, 30 Sep 2007 13:54:56 -0400
From: Daniel Jacobowitz <drow@false.org>
To: offlineimap@complete.org
Subject: Assorted patches
Here's the result of a lazy Sunday hacking on offlineimap. Sorry for
not breaking this into multiple patches. They're mostly logically
independent so just ask if that would make a difference.
First, a new -q (quick) option. The quick option means to only update
folders that seem to have had significant changes. For Maildir, any
change to any message UID or flags is significant, because checking
the flags doesn't add a significant cost. For IMAP, only a change to
the total number of messages or a change in the UID of the most recent
message is significant. This should catch everything except for
flags changes.
The difference in bandwidth is astonishing: a quick sync takes 80K
instead of 5.3MB, and 28 seconds instead of 90.
There's a configuration variable that lets you say every tenth sync
should update flags, but let all the intervening ones be lighter.
Second, a fix to the UID validity problems many people have been
reporting with Courier. As discussed in Debian bug #433732, I changed
the UID validity check to use SELECT unless the server complains that
the folder is read-only. This avoids the Courier bug (see the Debian
log for more details). This won't fix existing validity errors, you
need to remove the local status and validity files by hand and resync.
Third, some speedups in Maildir checking. It's still pretty slow
due to a combination of poor performance in os.listdir (never reads
more than 4K of directory entries at a time) and some semaphore that
leads to lots of futex wake operations, but at least this saves
20% or so of the CPU time running offlineimap on a single folder:
Time with quick refresh and md5 in loop: 4.75s user 0.46s system 12%
cpu 41.751 total
Time with quick refresh and md5 out of loop: 4.38s user 0.50s system
14% cpu 34.799 total
Time using string compare to check folder: 4.11s user 0.47s system 13%
cpu 34.788 total
And fourth, some display fixes for Curses.Blinkenlights. I made
warnings more visible, made the new quick sync message cyan, and
made all not explicitly colored messages grey. That last one was
really bugging me. Any time OfflineIMAP printed a warning in
this UI, it had even odds of coming out black on black!
Anyway, I hope these are useful. I'm happy to revise them if you see
a problem.
--
Daniel Jacobowitz
CodeSourcery
2007-10-01 23:20:37 +02:00
|
|
|
|
2014-08-03 14:47:26 +02:00
|
|
|
|
|
|
|
# Interface from BaseFolder
|
|
|
|
def msglist_item_initializer(self, uid):
|
|
|
|
return {'flags': set(), 'filename': '/no-dir/no-such-file/'}
|
|
|
|
|
2014-03-16 13:27:35 +01:00
|
|
|
# Interface from BaseFolder
|
2002-07-16 04:26:58 +02:00
|
|
|
def cachemessagelist(self):
|
2015-02-13 17:02:33 +01:00
|
|
|
if self.ismessagelistempty():
|
Daniel Jacobowitz patches
fixes deb#433732
Date: Sun, 30 Sep 2007 13:54:56 -0400
From: Daniel Jacobowitz <drow@false.org>
To: offlineimap@complete.org
Subject: Assorted patches
Here's the result of a lazy Sunday hacking on offlineimap. Sorry for
not breaking this into multiple patches. They're mostly logically
independent so just ask if that would make a difference.
First, a new -q (quick) option. The quick option means to only update
folders that seem to have had significant changes. For Maildir, any
change to any message UID or flags is significant, because checking
the flags doesn't add a significant cost. For IMAP, only a change to
the total number of messages or a change in the UID of the most recent
message is significant. This should catch everything except for
flags changes.
The difference in bandwidth is astonishing: a quick sync takes 80K
instead of 5.3MB, and 28 seconds instead of 90.
There's a configuration variable that lets you say every tenth sync
should update flags, but let all the intervening ones be lighter.
Second, a fix to the UID validity problems many people have been
reporting with Courier. As discussed in Debian bug #433732, I changed
the UID validity check to use SELECT unless the server complains that
the folder is read-only. This avoids the Courier bug (see the Debian
log for more details). This won't fix existing validity errors, you
need to remove the local status and validity files by hand and resync.
Third, some speedups in Maildir checking. It's still pretty slow
due to a combination of poor performance in os.listdir (never reads
more than 4K of directory entries at a time) and some semaphore that
leads to lots of futex wake operations, but at least this saves
20% or so of the CPU time running offlineimap on a single folder:
Time with quick refresh and md5 in loop: 4.75s user 0.46s system 12%
cpu 41.751 total
Time with quick refresh and md5 out of loop: 4.38s user 0.50s system
14% cpu 34.799 total
Time using string compare to check folder: 4.11s user 0.47s system 13%
cpu 34.788 total
And fourth, some display fixes for Curses.Blinkenlights. I made
warnings more visible, made the new quick sync message cyan, and
made all not explicitly colored messages grey. That last one was
really bugging me. Any time OfflineIMAP printed a warning in
this UI, it had even odds of coming out black on black!
Anyway, I hope these are useful. I'm happy to revise them if you see
a problem.
--
Daniel Jacobowitz
CodeSourcery
2007-10-01 23:20:37 +02:00
|
|
|
self.messagelist = self._scanfolder()
|
2012-01-06 13:05:08 +01:00
|
|
|
|
2014-03-16 13:27:35 +01:00
|
|
|
# Interface from BaseFolder
|
2002-06-20 05:33:23 +02:00
|
|
|
def getmessagelist(self):
|
|
|
|
return self.messagelist
|
2002-06-19 08:08:59 +02:00
|
|
|
|
2014-03-16 13:27:35 +01:00
|
|
|
# Interface from BaseFolder
|
2002-06-20 06:59:57 +02:00
|
|
|
def getmessage(self, uid):
|
2015-01-01 21:41:11 +01:00
|
|
|
"""Return the content of the message."""
|
|
|
|
|
2002-07-24 01:36:44 +02:00
|
|
|
filename = self.messagelist[uid]['filename']
|
2011-06-10 17:32:40 +02:00
|
|
|
filepath = os.path.join(self.getfullname(), filename)
|
|
|
|
file = open(filepath, 'rt')
|
2002-06-20 06:59:57 +02:00
|
|
|
retval = file.read()
|
|
|
|
file.close()
|
2011-06-10 17:32:40 +02:00
|
|
|
#TODO: WHY are we replacing \r\n with \n here? And why do we
|
|
|
|
# read it as text?
|
2002-07-22 07:29:26 +02:00
|
|
|
return retval.replace("\r\n", "\n")
|
2002-06-20 06:59:57 +02:00
|
|
|
|
2014-03-16 13:27:35 +01:00
|
|
|
# Interface from BaseFolder
|
2011-08-30 12:36:55 +02:00
|
|
|
def getmessagetime(self, uid):
|
2006-08-22 03:09:36 +02:00
|
|
|
filename = self.messagelist[uid]['filename']
|
2011-06-10 17:32:40 +02:00
|
|
|
filepath = os.path.join(self.getfullname(), filename)
|
2011-08-30 12:36:55 +02:00
|
|
|
return os.path.getmtime(filepath)
|
2006-08-22 03:09:36 +02:00
|
|
|
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
def new_message_filename(self, uid, flags=set(), rtime=None):
|
2011-08-30 10:51:33 +02:00
|
|
|
"""Creates a new unique Maildir filename
|
|
|
|
|
|
|
|
:param uid: The UID`None`, or a set of maildir flags
|
|
|
|
:param flags: A set of maildir flags
|
|
|
|
:returns: String containing unique message filename"""
|
2015-01-01 21:41:11 +01:00
|
|
|
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
# Prefer internal time (rtime) over retrieval time (_gettimeseq()) for
|
|
|
|
# consistency in the maxage check, which compares times of local mail
|
|
|
|
# (gotten from the filename) to the internal time of the remote mail.
|
|
|
|
if rtime is None:
|
|
|
|
timeval, timeseq = _gettimeseq()
|
|
|
|
else:
|
|
|
|
timeval, timeseq = rtime, 0
|
|
|
|
|
|
|
|
def build_filename(timeval, timeseq, pid, hostname, uid, folder_id,
|
|
|
|
infosep, flags):
|
|
|
|
"""Compute a new filename with 'time sequence' uniqueness in mind."""
|
|
|
|
filename = '%d_%d.%d.%s,U=%d,FMD5=%s%s2,%s'% (
|
|
|
|
timeval, timeseq, pid, hostname, uid, folder_id, infosep, flags)
|
|
|
|
for imap_dir in ['cur', 'new', 'tmp']:
|
|
|
|
if os.path.exists(os.path.join(self.getfullname(), imap_dir,
|
|
|
|
filename)):
|
|
|
|
# Increase timeseq.
|
|
|
|
return build_filename(timeval, timeseq + 1, pid, hostname,
|
|
|
|
uid, folder_id, infosep, flags)
|
|
|
|
return filename
|
|
|
|
|
|
|
|
return build_filename(timeval, timeseq, os.getpid(), socket.gethostname(),
|
2015-01-14 22:58:25 +01:00
|
|
|
uid, self._foldermd5, self.infosep, ''.join(sorted(flags)))
|
2013-07-21 21:00:23 +02:00
|
|
|
|
2012-10-16 20:20:35 +02:00
|
|
|
|
|
|
|
def save_to_tmp_file(self, filename, content):
|
2015-01-01 21:41:11 +01:00
|
|
|
"""Saves given content to the named temporary file in the
|
2012-10-16 20:20:35 +02:00
|
|
|
'tmp' subdirectory of $CWD.
|
|
|
|
|
|
|
|
Arguments:
|
|
|
|
- filename: name of the temporary file;
|
|
|
|
- content: data to be saved.
|
|
|
|
|
|
|
|
Returns: relative path to the temporary file
|
2015-01-01 21:41:11 +01:00
|
|
|
that was created."""
|
2012-10-16 20:20:35 +02:00
|
|
|
|
|
|
|
tmpname = os.path.join('tmp', filename)
|
|
|
|
# open file and write it out
|
|
|
|
tries = 7
|
|
|
|
while tries:
|
|
|
|
tries = tries - 1
|
|
|
|
try:
|
|
|
|
fd = os.open(os.path.join(self.getfullname(), tmpname),
|
|
|
|
os.O_EXCL|os.O_CREAT|os.O_WRONLY, 0o666)
|
|
|
|
break
|
|
|
|
except OSError as e:
|
|
|
|
if e.errno == e.EEXIST:
|
|
|
|
if tries:
|
2014-05-06 23:12:50 +02:00
|
|
|
time.sleep(0.23)
|
2012-10-16 20:20:35 +02:00
|
|
|
continue
|
|
|
|
severity = OfflineImapError.ERROR.MESSAGE
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
raise OfflineImapError("Unique filename %s already exists."%
|
|
|
|
filename, severity), None, exc_info()[2]
|
2012-10-16 20:20:35 +02:00
|
|
|
else:
|
|
|
|
raise
|
|
|
|
|
|
|
|
fd = os.fdopen(fd, 'wt')
|
|
|
|
fd.write(content)
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
# Make sure the data hits the disk.
|
2012-10-16 20:20:35 +02:00
|
|
|
fd.flush()
|
|
|
|
if self.dofsync:
|
|
|
|
os.fsync(fd)
|
|
|
|
fd.close()
|
|
|
|
|
|
|
|
return tmpname
|
|
|
|
|
|
|
|
|
2014-03-16 13:27:35 +01:00
|
|
|
# Interface from BaseFolder
|
2006-08-22 03:09:36 +02:00
|
|
|
def savemessage(self, uid, content, flags, rtime):
|
2011-09-16 11:44:50 +02:00
|
|
|
"""Writes a new message, with the specified uid.
|
|
|
|
|
|
|
|
See folder/Base for detail. Note that savemessage() does not
|
|
|
|
check against dryrun settings, so you need to ensure that
|
|
|
|
savemessage is never called in a dryrun mode."""
|
2007-06-13 05:42:15 +02:00
|
|
|
# This function only ever saves to tmp/,
|
|
|
|
# but it calls savemessageflags() to actually save to cur/ or new/.
|
2011-09-16 11:44:50 +02:00
|
|
|
self.ui.savemessage('maildir', uid, flags, self)
|
2002-06-21 03:03:30 +02:00
|
|
|
if uid < 0:
|
|
|
|
# We cannot assign a new uid.
|
|
|
|
return uid
|
2011-09-16 11:44:50 +02:00
|
|
|
|
2002-07-24 01:36:44 +02:00
|
|
|
if uid in self.messagelist:
|
2011-06-10 17:32:40 +02:00
|
|
|
# We already have it, just update flags.
|
2002-06-21 03:12:52 +02:00
|
|
|
self.savemessageflags(uid, flags)
|
2002-06-21 03:03:30 +02:00
|
|
|
return uid
|
2007-06-13 05:42:15 +02:00
|
|
|
|
|
|
|
# Otherwise, save the message in tmp/ and then call savemessageflags()
|
|
|
|
# to give it a permanent home.
|
2002-06-20 06:59:57 +02:00
|
|
|
tmpdir = os.path.join(self.getfullname(), 'tmp')
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
# Make sure rtime is the internal date, so it can be put in the filename
|
|
|
|
if rtime is None:
|
|
|
|
rtime = emailutil.get_message_date(content)
|
|
|
|
messagename = self.new_message_filename(uid, flags, rtime=rtime)
|
2012-10-16 20:20:35 +02:00
|
|
|
tmpname = self.save_to_tmp_file(messagename, content)
|
2006-12-02 21:54:26 +01:00
|
|
|
if rtime != None:
|
2012-10-16 20:20:35 +02:00
|
|
|
os.utime(os.path.join(self.getfullname(), tmpname), (rtime, rtime))
|
2007-03-28 22:23:18 +02:00
|
|
|
|
2014-08-03 14:47:26 +02:00
|
|
|
self.messagelist[uid] = self.msglist_item_initializer(uid)
|
|
|
|
self.messagelist[uid]['flags'] = flags
|
|
|
|
self.messagelist[uid]['filename'] = tmpname
|
2011-06-10 17:32:40 +02:00
|
|
|
# savemessageflags moves msg to 'cur' or 'new' as appropriate
|
2002-06-21 03:12:52 +02:00
|
|
|
self.savemessageflags(uid, flags)
|
2011-01-05 17:00:57 +01:00
|
|
|
self.ui.debug('maildir', 'savemessage: returning uid %d' % uid)
|
2002-06-21 03:03:30 +02:00
|
|
|
return uid
|
2012-01-06 13:05:08 +01:00
|
|
|
|
2014-03-16 13:27:35 +01:00
|
|
|
# Interface from BaseFolder
|
2002-06-20 07:14:35 +02:00
|
|
|
def getmessageflags(self, uid):
|
2002-07-24 01:36:44 +02:00
|
|
|
return self.messagelist[uid]['flags']
|
2002-06-20 07:14:35 +02:00
|
|
|
|
2014-03-16 13:27:35 +01:00
|
|
|
# Interface from BaseFolder
|
2002-06-20 07:14:35 +02:00
|
|
|
def savemessageflags(self, uid, flags):
|
2011-08-30 10:52:11 +02:00
|
|
|
"""Sets the specified message's flags to the given set.
|
2011-07-12 09:34:02 +02:00
|
|
|
|
2011-08-30 10:52:11 +02:00
|
|
|
This function moves the message to the cur or new subdir,
|
2011-09-16 11:44:50 +02:00
|
|
|
depending on the 'S'een flag.
|
2011-08-30 10:43:10 +02:00
|
|
|
|
2011-09-16 11:44:50 +02:00
|
|
|
Note that this function does not check against dryrun settings,
|
|
|
|
so you need to ensure that it is never called in a
|
|
|
|
dryrun mode."""
|
2014-08-03 14:47:26 +02:00
|
|
|
|
|
|
|
assert uid in self.messagelist
|
|
|
|
|
2011-08-30 10:52:11 +02:00
|
|
|
oldfilename = self.messagelist[uid]['filename']
|
|
|
|
dir_prefix, filename = os.path.split(oldfilename)
|
|
|
|
# If a message has been seen, it goes into 'cur'
|
|
|
|
dir_prefix = 'cur' if 'S' in flags else 'new'
|
2012-01-06 13:05:08 +01:00
|
|
|
|
2011-08-30 10:43:10 +02:00
|
|
|
if flags != self.messagelist[uid]['flags']:
|
2012-01-07 21:34:57 +01:00
|
|
|
# Flags have actually changed, construct new filename Strip
|
|
|
|
# off existing infostring (possibly discarding small letter
|
|
|
|
# flags that dovecot uses TODO)
|
2012-01-07 13:10:41 +01:00
|
|
|
infomatch = self.re_flagmatch.search(filename)
|
2011-08-30 10:43:10 +02:00
|
|
|
if infomatch:
|
|
|
|
filename = filename[:-len(infomatch.group())] #strip off
|
2015-01-01 21:41:11 +01:00
|
|
|
infostr = '%s2,%s'% (self.infosep, ''.join(sorted(flags)))
|
2011-08-30 10:43:10 +02:00
|
|
|
filename += infostr
|
|
|
|
|
|
|
|
newfilename = os.path.join(dir_prefix, filename)
|
2002-06-20 07:14:35 +02:00
|
|
|
if (newfilename != oldfilename):
|
2011-08-17 10:01:39 +02:00
|
|
|
try:
|
|
|
|
os.rename(os.path.join(self.getfullname(), oldfilename),
|
|
|
|
os.path.join(self.getfullname(), newfilename))
|
2012-02-05 10:14:23 +01:00
|
|
|
except OSError as e:
|
2011-08-17 10:01:39 +02:00
|
|
|
raise OfflineImapError("Can't rename file '%s' to '%s': %s" % (
|
|
|
|
oldfilename, newfilename, e[1]),
|
2015-01-11 21:44:24 +01:00
|
|
|
OfflineImapError.ERROR.FOLDER), \
|
|
|
|
None, exc_info()[2]
|
2012-01-06 13:05:08 +01:00
|
|
|
|
2002-07-24 01:36:44 +02:00
|
|
|
self.messagelist[uid]['flags'] = flags
|
|
|
|
self.messagelist[uid]['filename'] = newfilename
|
2002-06-20 07:14:35 +02:00
|
|
|
|
2014-03-16 13:27:35 +01:00
|
|
|
# Interface from BaseFolder
|
2011-08-30 10:52:11 +02:00
|
|
|
def change_message_uid(self, uid, new_uid):
|
|
|
|
"""Change the message from existing uid to new_uid
|
2007-06-13 05:42:15 +02:00
|
|
|
|
2011-08-30 10:52:11 +02:00
|
|
|
This will not update the statusfolder UID, you need to do that yourself.
|
|
|
|
:param new_uid: (optional) If given, the old UID will be changed
|
2015-01-01 21:41:11 +01:00
|
|
|
to a new UID. The Maildir backend can implement this as
|
|
|
|
an efficient rename.
|
|
|
|
"""
|
|
|
|
|
2011-08-30 10:52:11 +02:00
|
|
|
if not uid in self.messagelist:
|
2015-01-14 22:58:25 +01:00
|
|
|
raise OfflineImapError("Cannot change unknown Maildir UID %s"% uid)
|
2011-08-30 10:52:11 +02:00
|
|
|
if uid == new_uid: return
|
|
|
|
|
|
|
|
oldfilename = self.messagelist[uid]['filename']
|
|
|
|
dir_prefix, filename = os.path.split(oldfilename)
|
|
|
|
flags = self.getmessageflags(uid)
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
content = self.getmessage(uid)
|
|
|
|
rtime = emailutil.get_message_date(content)
|
2012-10-23 20:05:59 +02:00
|
|
|
newfilename = os.path.join(dir_prefix,
|
fix: don't loose local mails because of maxage
Suppose messages A and B were delivered to the remote folder at
"maxage + 1" days ago.
A was downloaded to the local folder "maxage + 1" days ago, but B was only
downloaded "maxage - 1" days ago (contrived scenario to illustrate the two
things that could happen). The behavior was that B gets deleted from the local
folder, but A did not. The expected behavior is that neither is deleted.
Starting where Base.py: __syncmessagesto_delete(self, dstfolder, statusfolder)
is called where:
- self is the remote folder
and
- dstfolder is the local folder.
It defines deletelist to be the list of messages in the status folder
messagelist that aren't in the remote folder messagelist with
not self.uidexists(uid)
A and B are both in the status folder. They're also both *NOT* in the remote
folder messagelist: this list is formed in IMAP.py: cachemessagelist(), which
calls _msgs_to_fetch(), which only asks the IMAP server for messages that are
"< maxage" days old.
Back to Base.py __syncmessagesto_delete(), look at the call
folder.deletemessages(deletelist), where folder is the local folder. This ends
up calling Maildir.py deletemessage() for each message on the deletelist. But we
see that this methods returns (instead of deleting anything) if the message is
in the local folder's messagelist. This messagelist was created by Maildir.py's
cachemessagelist(), which calls _scanfolder(), which tries to exclude messages
based on maxage. So at this point, we *WANT* A and B to be excluded -- then they
will be spared from deletion. This maxage check calls _iswithinmaxage(), and
actually does the date comparison based on the time found at the beginning of
the message's filename. These filenames were originally created in Maildir.py's
new_message_filename(), which calls _gettimeseq() to get the current time (i.e.
the time of retrieval).
Upshot: A's filename has an older timestamp than B's filename. A is excluded
from the local folder messagelist in _scanfolder(), hence spared from deletion
in deletemessage(); B is not excluded, and is deleted.
This patch does not address the timezone issue. As for the IMAP/timezone issue,
a similar issue is discussed in the thunderbird bug tracker here:
https://bugzilla.mozilla.org/show_bug.cgi?id=886534
In the end, they're solving a different problem, but they agree that
there is really no reliable way of guessing the IMAP server's internal
timezone.
Signed-off-by: Janna Martl <janna.martl109@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2015-03-07 10:50:33 +01:00
|
|
|
self.new_message_filename(new_uid, flags, rtime=rtime))
|
2011-08-30 10:52:11 +02:00
|
|
|
os.rename(os.path.join(self.getfullname(), oldfilename),
|
2012-10-23 20:05:59 +02:00
|
|
|
os.path.join(self.getfullname(), newfilename))
|
2011-08-30 10:52:11 +02:00
|
|
|
self.messagelist[new_uid] = self.messagelist[uid]
|
2012-10-23 20:05:59 +02:00
|
|
|
self.messagelist[new_uid]['filename'] = newfilename
|
2011-08-30 10:52:11 +02:00
|
|
|
del self.messagelist[uid]
|
2013-07-21 21:00:23 +02:00
|
|
|
|
2014-03-16 13:27:35 +01:00
|
|
|
# Interface from BaseFolder
|
2002-06-20 07:14:35 +02:00
|
|
|
def deletemessage(self, uid):
|
2011-05-07 11:11:20 +02:00
|
|
|
"""Unlinks a message file from the Maildir.
|
|
|
|
|
|
|
|
:param uid: UID of a mail message
|
|
|
|
:type uid: String
|
|
|
|
:return: Nothing, or an Exception if UID but no corresponding file
|
|
|
|
found.
|
|
|
|
"""
|
2002-07-24 01:36:44 +02:00
|
|
|
filename = self.messagelist[uid]['filename']
|
2011-06-10 17:32:40 +02:00
|
|
|
filepath = os.path.join(self.getfullname(), filename)
|
2002-07-16 04:26:58 +02:00
|
|
|
try:
|
2011-06-10 17:32:40 +02:00
|
|
|
os.unlink(filepath)
|
2002-08-17 03:01:12 +02:00
|
|
|
except OSError:
|
2002-07-16 04:26:58 +02:00
|
|
|
# Can't find the file -- maybe already deleted?
|
|
|
|
newmsglist = self._scanfolder()
|
|
|
|
if uid in newmsglist: # Nope, try new filename.
|
2011-06-10 17:32:40 +02:00
|
|
|
filename = newmsglist[uid]['filename']
|
|
|
|
filepath = os.path.join(self.getfullname(), filename)
|
|
|
|
os.unlink(filepath)
|
2002-07-16 04:26:58 +02:00
|
|
|
# Yep -- return.
|
2002-06-20 07:14:35 +02:00
|
|
|
del(self.messagelist[uid])
|