Hi! Wilfred,

On 08/17/2017 04:39 PM, you wrote:

 WV>>> It would be easier if you confirmed it's working, otherwise you can
 WV>>> come back about this next year, when I completely forgot about the
 WV>>> details... ;)

 NB>> In that case, it's working just fine now. Thank you for the
 WvV> hotfix! ;)

 WvV> Thanks for the confirmation...

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

If it's send-related (aka fmail scan) then not at this time, thanks. I'm
quietly watching just the tossing activity and monitoring the contents of
the messagebase, while fine-tuning GoldEd... and, loving it.  :)

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

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

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

I did go back to FConfigW32 and enable message sorting but the ordering
still didn't seem normal compared with what I see tossed into the Crashmail
messagebase... ermmm, just checking... nah, they check out with GoldEd
(here) as being in the as-created order.

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

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0