So point for improvement...
A minor one. If anything its omission is just an annoyance but not critical.
A minor one. If anything its omission is just an
annoyance but not critical.
Adding 1 or 2 lines to the doc, shouldn't be a problem,
because it's so time consuming... ;)
@TZUTC: -0500
@CHRS: UTF-8 4
@MSGID: 1:154/10.1 598b9a0a
Hello All,
The other ones didn't work, so let's try this one.
Regards,
Nick
... "Не знаю. Я здесь только работаю."
--- FMail-lnx 2.1.0.17-B20170804
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10.1) SEEN-BY: 116/116 123/141 135/300 140/1 154/10 20 30 40 700 261/38 340/800 SEEN-BY: 3634/12 15 22 24 27 50
@PATH: 154/10 3634/12
Just seems I'm having an issue with echomail.jam now. Golded creates it in the right place,
but running "fmail scan" seems to find it, and delete it, but doesn't actually scan out the message.
"fmail scan -S" finds the message and scans it out, though. Odd.
I haven't tried any sending silliness yet. I've config'd GoldEd to
place those files in the semaphore directory but now thinking on it,
maybe they should go where the messagebase directory is located. What have you come up with?
Just seems I'm having an issue with echomail.jam now. Golded creates
it in the right place, but running "fmail scan" seems to find it, and
delete it, but doesn't actually scan out the message. "fmail scan -S"
finds the message and scans it out, though. Odd.
I never had a problem with it. But you can look inside it with any editor before you run 'fmail scan'. It's just a plain txt file.
-S should. That option ignores echomail.jam, and scans every area for unsend messages front to back.
Maybe I need to add some more logging? ;)
traditionally, echomail.jam and netmail.jam are placed in the message
base directory where the hudson message base files are or would be created... this was developed jointly by the remoteaccess and fastecho devs when the JAM format was first introduced by the frontdoor and remoteaccess teams... traditional mail tossers will look for those file where the HMB is...
created... this was developed jointly by the remoteaccess and fastecho
devs when the JAM format was first introduced by the frontdoor and
remoteaccess teams... traditional mail tossers will look for those
file where the HMB is...
Yes. It is an old lesson re-learned.
While both packages insist on having a HMB, FastEcho's unused one has
been situated on a 256Kb(!) RAM drive for the last ~15 years, with semaphores and other text files in separate dirs. A body can't do
that with FMail, as that is where the Badmail & Dupes are forced.
Arggghhh! ;-)
I never had a problem with it. But you can look inside it with any
editor before you run 'fmail scan'. It's just a plain txt file.
-S should. That option ignores echomail.jam, and scans every area for unsend messages front to back.
Maybe I need to add some more logging? ;)
While I was adding some debug logging to the echomail.jam processing
code, I found a bug. The paths in the echomail.jam file and those for
the jam areas in the config weren't converted to linux paths before comparing them. On my system this wasn't a problem because of some
script code that runs after I leave golded-lnx to fix the paths to
their dos versions in echomail.jam, because of my previous hibrid
system. A fixed version of fmail.c is in your inbound...
Hi Nicholas,
-S should. That option ignores echomail.jam, and scans every
area for unsend messages front to back.
Maybe I need to add some more logging? ;)
While I was adding some debug logging to the echomail.jam processing
code, I found a bug. The paths in the echomail.jam file and those for
the jam areas in the config weren't converted to linux paths before comparing them. On my system this wasn't a problem because of some
script code that runs after I leave golded-lnx to fix the paths to
their dos versions in echomail.jam, because of my previous hibrid
system. A fixed version of fmail.c is in your inbound...
While both packages insist on having a HMB, FastEcho's unused one has
been situated on a 256Kb(!) RAM drive for the last ~15 years, with semaphores and other text files in separate dirs. A body can't do
that with FMail, as that is where the Badmail & Dupes are forced.
Testing bugfix. If I don't reply about the same matter, consider it working as expected! ;)
It's on the to-do list! ;)
But priority is on the linux version right now...
But priority is on the linux version right now...
Yes, boss. I like how you talk! :)
But priority is on the linux version right now...
Yes, boss. I like how you talk! :)
Do I seem bossy? Should I sugar coat it somehow? ;)
Maybe I should have referred to you as 'chief' but I wasn't sure how
you take that, so I didn't. ;-)
While both packages insist on having a HMB, FastEcho's unused oneIt's on the to-do list! ;)
has been situated on a 256Kb(!) RAM drive for the last ~15 years,
with semaphores and other text files in separate dirs. A body
can't do that with FMail, as that is where the Badmail & Dupes
are forced.
But priority is on the linux version right now...
Testing bugfix. If I don't reply about the same matter, consider
it working as expected! ;)
It would be easier if you confirmed it's working, otherwise you can
come back about this next year, when I completely forgot about the details... ;)
As soon as JAM only is possible on Linux, I will also try ;))
As soon as JAM only is possible on Linux, I will also try ;))JAM only? As in netmail too? JAM message bases are already possible on Linux. ;)
While both packages insist on having a HMB, FastEcho's unused one
has been situated on a 256Kb(!) RAM drive for the last ~15 years,
with semaphores and other text files in separate dirs. A body
can't do that with FMail, as that is where the Badmail & Dupes
are forced.
It's on the to-do list! ;)
But priority is on the linux version right now...
As soon as JAM only is possible on Linux, I will also try ;))
It would be easier if you confirmed it's working, otherwise you can
come back about this next year, when I completely forgot about the
details... ;)
In that case, it's working just fine now. Thank you for the hotfix! ;)
one?It would be easier if you confirmed it's working, otherwise you can
come back about this next year, when I completely forgot about the
details... ;)
In that case, it's working just fine now. Thank you for thehotfix! ;)
Thanks for the confirmation...
Btw: If Paul wants/needs a 32 bit version with this fix, I can provide
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.
It's on the to-do list! ;)
But priority is on the linux version right now...
As soon as JAM only is possible on Linux, I will also try ;))I better start working then! ;)
As soon as the native Linux version of FMail supports a pure JAM setup under Linux including setup.
I hope it is more understandable now :-P
It's on the to-do list! ;)
But priority is on the linux version right now...
As soon as JAM only is possible on Linux, I will also try ;))
I better start working then! ;)
;))
I have time ...
Sysop: | digital man |
---|---|
Location: | Riverside County, California |
Users: | 1,048 |
Nodes: | 15 (0 / 15) |
Uptime: | 55:56:28 |
Calls: | 236,049 |
Calls today: | 8 |
Files: | 60,363 |
D/L today: |
12,171 files (2,252M bytes) |
Messages: | 289,498 |
Posted today: | 6 |