more on maildir modification times!

Janna Martl janna.martl109 at gmail.com
Thu Apr 2 03:29:15 BST 2015


On Thu, Mar 26, 2015 at 12:07:13PM +0100, Nicolas Sebrecht wrote:
>On Thu, Mar 26, 2015 at 03:29:20AM +0100, Nicolas Sebrecht wrote:
>
>> I suggest to wait I revert the patch if you'd like to go further,
>> though.
>
>Done.

I think I know what's going on here, and if we don't do something about
it, this problem will come back when our timezone thing gets merged. The
commit that got reverted did the following (in folder/Maildir.py):

def savemessage(self, uid, content, flags, rtime):
    """Writes a new message, with the specified uid.
    <...>

+    if rtime is None:
+        rtime = emailutil.get_message_date(content)
+    messagename = self.new_message_filename(uid, flags, rtime=rtime)
-    messagename = self.new_message_filename(uid, flags)
    tmpname = self.save_to_tmp_file(messagename, content)
    if rtime != None:
        os.utime(os.path.join(self.getfullname(), tmpname), (rtime, rtime))

In other words, that last line messing with the mtime was always there,
but the offending patch caused rtime to not be None. Why was it None?
Look at folder/IMAP.py:

def cachemessagelist(self):
    <...>

        res_type, response = imapobj.fetch("'%s'"%
            msgsToFetch, '(FLAGS UID)')
        <...>

    for messagestr in response:
        <...>
            rtime = imaplibutil.Internaldate2epoch(messagestr)
            self.messagelist[uid] = {'uid': uid, 'flags': flags, 'time': rtime}

It was None because we weren't even asking the IMAP server for the
INTERNALDATE, and then (penultimate line) tried to extract rtime from
the response. Obviously, that failed.

That was a bug, which I fixed in the current timezone WIP by adding
INTERNALDATE to the list of message properties the IMAP server should
return. But a consequence of this is now rtime won't be None anymore in
savemessage() above, and that os.utime call will actually happen.

Why don't we just get rid of the os.utime call? Why is it there in the
first place? It seems to be trying (and, up until now, failing) to do
exactly what people don't want.


-- J.M.




More information about the OfflineIMAP-project mailing list