more on maildir modification times!

Abdó Roig-Maranges abdo.roig at
Thu Apr 2 11:09:30 BST 2015


When I started this thread I was thinking the same as Janna, removing that os.utime(...)
line from savemessage is what I had in mind, but...

> I think rtime can be set by utime_from_message from 3bc66c0858ecc2e6
> that I recently changed to utime_from_header in 3bc66c0858ecc2e6.

I was not aware of the utime_from_header option, which seems to be the reason
for passing rtime to savemessage in the first place! See copymessageto from

When utime_from_header=false, copymessageto (from folder/ always passes
rtime=None to savemessage on the target folder. That's by design! It only passes
a meaningful rtime when utime_from_header=true.

> 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))

Janna, This change breaks the utime_from_header behaviour. if utime_from_header
= false, savemessage gets rtime=None, but you set it to the internal date, and
then the modification time for the file is changed despite utime_from_header =

A minimal solution is to keep rtime as is, and only touch the time in the

> +    mtime = emailutil.get_message_date(content)
> +    messagename = self.new_message_filename(uid, flags, rtime=mtime)
> -    messagename = self.new_message_filename(uid, flags)

I think a better solution would be cleaning up the utime_from_header
thing. savemessage could handle the utime_from_header check. Then
folder/'s copymessageto should forget about passing the rtime around!

I can send a patches now or wait until your timezone thing gets merged, as you

> 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's not the whole picture. folder/'s copymessageto overrides the buggy
rtime when utime_from_header=true. This is a mess...

Abdó Roig.

More information about the OfflineIMAP-project mailing list