Subj : Squish __ftsc_date bug / JAM bug
To   : Kai Richter
From : andrew clarke
Date : Tue Feb 16 2021 15:30:28

15 Feb 21 21:39, you wrote to me:

 KR> The bug is that the normal scan and the rescan created different
 KR> DateTime.

 KR> I don't understand what you are doing but it looks like you do some
 KR> re-invention. Isn't it easier to look how the scan.c does the export and
 KR> use the same code for the rescan?

To summarise:

"toss" shouldn't need the message base, instead just memcpy()ing the ftscdate field between .PKTs. This is how PassThru areas work but should also be true for non-PassThru.

"scan" only exports local messages which in the case of a Squish base, only the DateWritten field is supposed to be written to by the mail reader, though Oli recently said that GoldED apparently writes the ftscdate field as well (which then means you can have a one second discrepancy between fields for the same locally written message...).

"rescan" exports both local and non-local messages, which can have a combination of DateWritten field ONLY or DateWritten-and-ftscdate, and HPT incorrectly uses the DateWritten field for non-local messages, which only has a two second resolution in Squish.

I can't say any more about JAM other than what I've already written.

The *.MSG format stores the date solely in ftscdate format, so HPT should really have no choice but to memcpy() the ftscdate field into the outbound PKT on a rescan.

So obviously the moral of the story is for everyone to use *.MSG. ;)

--- GoldED+/BSD 1.1.5-b20180707
 * Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)

.