GNOME Bugzilla – Bug 756842
[Maildir] Do not overwrite received date on the message info
Last modified: 2015-10-21 09:57:46 UTC
Copying folders using Copy Folder To does not preserve Received date. Instead the date is reset to time of copy operation. This may be tied to EWS backend which is what I am using.
Thanks for a bug report. Let's set Received date from the message ID only if the message itself doesn't contain Received header, otherwise use the value from the header, as the other providers do. Created commit 0d1cf50 in eds master (3.19.1+) Created commit f1044d6 in eds gnome-3-18 (3.18.2+)
I backported the bug fix to data-server 3.16.5 and redid the copy: It worked for about half the mails, the other half had the time of copy operation.
(In reply to joakim.tjernlund from comment #2) > I backported the bug fix to data-server 3.16.5 and redid the copy: It worked > for about half the mails, the other half had the time of copy operation. Right. As I wrote above, it's for cases when the Received header is available. Otherwise (when there is no good guess), the value of the "current time" is used. Check the message source (Ctrl+U) and you might see no Received header in those emails.
(In reply to Milan Crha from comment #3) > (In reply to joakim.tjernlund from comment #2) > > I backported the bug fix to data-server 3.16.5 and redid the copy: It worked > > for about half the mails, the other half had the time of copy operation. > > Right. As I wrote above, it's for cases when the Received header is > available. Otherwise (when there is no good guess), the value of the > "current time" is used. Check the message source (Ctrl+U) and you might see > no Received header in those emails. It does not make sense, Received is present and OK in the src folder but is lost after copying. You are correct that the Received: header is missing, why I do not known, but the src Folders still present Received which is different from Date: by 1-2 minutes or so.
Created attachment 313768 [details] [review] partial patch for evolution-data-server; This will do it, but only if the caller set the right message info with the filled received date. That worked for me in case of the evolution-ews message (which didn't have the received header, like those messages in the Sent folder), but not for an IMAPx account, thus this needs more work than just in the maildir code, but also in the other providers' code. Feel free to test this partial fix, I'll return to this shortly (tomorrow or so).
Did a quick test and it worked :) I understand this is a quick fix but just in case: 1) I think you should prefer Received iff it exists and then fallback to other means. 2) I case of Copy operation, always write a real Received: header so one does not need to rely on magic code to construct one.
The patch from comment #5 relies on accuracy of the received date value provided by the caller. It also affects the result only in the case where the caller sets the received date. Both your points are covered by the previous commit (comment #1), but I will extend it to this new part too.
I realized, after further investigation, that in the case of the IMAPx it's correct. It fully relies on the Received header, it doesn't ensure it by creating an artificial value, thus the messages without that header doesn't have the received value filled at all. That means that the patch from comment #5 is basically it, I only slightly extended it. Created commit 4c74c15 in eds master (3.19.1+) Created commit c6ecd77 in eds gnome-3-18 (3.18.2+)
(In reply to Milan Crha from comment #8) > I realized, after further investigation, that in the case of the IMAPx it's > correct. It fully relies on the Received header, it doesn't ensure it by > creating an artificial value, thus the messages without that header doesn't > have the received value filled at all. That means that the patch from > comment #5 is basically it, I only slightly extended it. > > Created commit 4c74c15 in eds master (3.19.1+) > Created commit c6ecd77 in eds gnome-3-18 (3.18.2+) I see, thanks. I see that you have committed fixes to >= 3.18, does this mean that 3.16.x is not supported anymore?
(In reply to joakim.tjernlund from comment #9) > I see that you have committed fixes to >= 3.18, does this mean that > 3.16.x is not supported anymore? Correct, 3.16 is dead for upstream, due to limited man power. You can always ask your distribution maintainer(s) to backport the changes. Then it's up to them whether they'll do it or not.