more on maildir modification times!
Abdó Roig-Maranges
abdo.roig at gmail.com
Thu Apr 2 11:09:30 BST 2015
Hi,
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
folder/Base.py.
When utime_from_header=false, copymessageto (from folder/Base.py) 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 =
false.
A minimal solution is to keep rtime as is, and only touch the time in the
filename
> + 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/Base.py'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
prefer!
> 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/Base.py'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