Because a lot of IMAP clients are not easily convinced to ignore the internaldate and also because it cannot be changed on an IMAP server (other than recreating the message with a new UID), I looked into syncing the INTERNALDATE from IMAP to IMAP. What I did is quite similar to the patch that was made for 1.0.4, except it is based on the current git master and:
  • I did it just for IMAP, and tested only one way. (Anyway, as the internaldate is only set once during append, it should work both ways.)
  • I use a string instead of time_t, because for now I just rely on FETCH returning a valid date-time string suitable for APPEND. 
  • This is a testing version with some debug strings that will also provoke an APPEND-error if the internaldate is not valid. That is, so I can use the same channel repeatedly for testing. 

The last point was necessary because – it doesn't work!
The date gets fetched and parsed and is successfully assigned to the additional field of the msg_data_t struct. But while flags, len and data are passed all the way down to imap_store_msg, the date gets lost somewhere in between. 

As far as I can tell it boils down to this line in copy_msg: 
DRIVER_CALL_RET(fetch_msg( svars->ctx[t], vars->msg, &vars->data, msg_fetched, vars ));
fetch_msg eventually calls parse_fetch, where all the variables are assigned. But when msg_fetched is called, my date-string is filled with garbage. 

Honestly I have no idea, what exactly happens inside DRIVER_CALL_RET, I just got the idea that there are parallel IMAP-commands in_progress under the imap_store. What am I missing?

Greetings, 
Florian

Attachment: imap_internaldate.patch
Description: Binary data


------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel

Reply via email to