Hi Paul,

On 17 Aug 17 17:33, Paul Quinn wrote to Wilfred van Velzen:
  about: "New test..":

 WvV>> Btw: If Paul wants/needs a 32 bit version with this fix, I can
 WvV>> provide one?

 PQ> If it's send-related (aka fmail scan)

Yes.

 PQ> then not at this time, thanks.

Ok...

 PQ> I'm quietly watching just the tossing activity and monitoring the
 PQ> contents of the messagebase, while fine-tuning GoldEd... and, loving
 PQ> it.  

 PQ> All the JAM message area paths in Linux form were successfully imported
 PQ> into FMail from an Areas.Bbs created by my Crashmail II tosser (on this
 PQ> Linux system).  The netmail & HMB paths are converting correctly by 'fmail
 PQ> toss' using the "FMAIL_REPLACE_DRIVE" envar.

 PQ> GoldEd is set to use the same Areas.Bbs file that FConfigW32 imported,
 PQ> together with local handwritten converted paths for the netmail & HMB
 PQ> areas in its configuration file.  GoldEd has even been config'd to use the
 PQ> same echo descriptions files as Fmail is supposed to use, so GoldEd looks
 PQ> normal again.

 PQ> OTOH, I have noticed a slight weirdness in a local area (but still of
 PQ> 'echomail' type).  There's usually a batch of about 18-20 messages
 PQ> generated by FastEcho in the area over a period of about 5 seconds each
 PQ> morning.  They're landing in the Fmail messagebase 'out of order'.

Are they in 1 pkt file or several? You can look in the fmail log file in what
order the .pkt files are processed...

 PQ> I did go back to FConfigW32 and enable message sorting

If I'm not mistaken, the 'Sort new messages' option only works on the hudson
message base, not on the JAM areas.

 PQ> but the ordering still didn't seem normal compared with what I see
 PQ> tossed into the Crashmail messagebase... ermmm, just checking... nah,
 PQ> they check out with GoldEd (here) as being in the as-created order.

 PQ> I'll double-double check everything following tomorrow's activity, and
 PQ> advise formally if needed.

Ok...

Wilfred.

--- FMail-W32 2.0.1.4
 * Origin:  point@work  (2:280/464.112)