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
 * Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)