07 Sep 17 12:15:15 FMAIL Scanning JAM area 172: WIN95
07 Sep 17 12:15:15 FMAIL Echomail message, area WIN95
/opt/ftn/fido/outbound/02800180.hlo 07 Sep 17 12:15:15 FMAIL
Mail bundle already going from 3:640/1384 to 3:640/384 07 Sep 17
12:15:15 FMAIL Netmail: 0, Personal: 0, Hudson: 0, JAMbase: 1
07 Sep 17 12:15:15 FMAIL Msgbase net: 0, echo: 1, dup: 0, bad:
0 07 Sep 17 12:15:15 FMAIL Scan Active: 1.376 sec.
This log snippet doesn't mention anything about area "fec1e5dd". But
it does mention "WIN95". Something seems odd there,
..instead, and that is what FMail is looking for, but since it doesn't
see it, and nothing else was read from echomail.jam it deleted the
file.
The terminal screen says things about checking netmail & HMB, and
then JAM areas. Nothing about the echomail.jam file at all.
I believe I had asked about some better logging when echomail.jam fails too. ;)
I believe I had asked about some better logging when echomail.jam
fails too. ;)
Damned right! Or, at least a log entry that says "Nup, it's Thursday... I don't do echomail.jam files on Thursdays. Thank you for your co-operation". 8-)
Is that some sort of separate option or setting? I can only seem to
recall areatag-esque filenames created by FastEcho when I used it some ages ago. At least I don't remember any tosser I've ever used making filenames like that by default.
This is probably where I was confused when originally setting up FMail with an areas.bbs. I suppose I've just seen way too many different
formats of areas.bbs to know which is actually the _correct_ one.
Right. It was the areas.bbs format you had above that confused me, not
the echomail.jam format. Have you tried a test post on an echo not
cloned from FE to see if echomail.jam is read properly?
Something like "sabbath" option, with configurable rest
day of the week? Should I put that on the wish list? ;)
fixSomething like "sabbath" option, with configurable rest
day of the week? Should I put that on the wish list? ;)
I reckon it's about time we had software with 'attitude'. You know, Terminator-sized terror under the hood...
"HaHa-ha! Only one puny Echomail.Jam file? You need a diskful! Let's
that...". ;-)
--- 8< ---
/opt/ftn/fido/msgbase/fec1e5dd 8020
--- 8< ---
Is that the name of the jam area filenames (without the extensions)?
Just a little while ago, twice. The echomail.jam file read...
--- 8< ---
/opt/ftn/fido/msgbase/aviation 14
--- 8< ---
That was the second attempt... I forgot to check the file first time around. Oops. Lucky #13, it was. Don't look for them of course.
Nothing gets out of the glass menagerie alive. ;-)
I love watching you guys hard at work testing stuff. Fido and BBS land
is a better place for all the hard work you lad do :) *pat on the
back*
The jam file area name that is used on Pauls system is odd, but all is working fine...
It did see it and exported the message to Pauls outbound (if that
isn't clear yet?)...
I believe I had asked about some better logging when echomail.jam
fails too. ;)
It's there... In the debug version. Just have to clean that up a bit
for the production version. ;)
Right. It was the areas.bbs format you had above that confused
me, not the echomail.jam format. Have you tried a test post on an
echo not cloned from FE to see if echomail.jam is read properly?
echomail.jam was read correctly! (If that wasn't clear yet?) ;)
It did see it and exported the message to Pauls outbound (if that
isn't clear yet?)...
Very clear. However, the only reason it was scanned out is because his FMail scanned _every_ area, rather than just what was in the echomail.jam.
I believe I had asked about some better logging when echomail.jam
fails too. ;)
It's there... In the debug version. Just have to clean that up a bit
for the production version. ;)
Did you give Paul a compiled setup with the updated fmail.c you gave me that fixed linux paths in echomail.jam?
echomail.jam was read correctly! (If that wasn't clear yet?) ;)
Hmm, what I saw was that echomail.jam was deleted, and his entire message base was scanned instead of just the area given by echomail.jam.
Did I miss something?
echomail.jam was read correctly! (If that wasn't clear yet?) ;)
Hmm, what I saw was that echomail.jam was deleted, and his entire
message base was scanned instead of just the area given by
echomail.jam.
Did I miss something?
Maybe you're right. ;)
I'll gona give Paul a version with the extra logging, so we can find out for sure...
If I didn't try things out and report any findings, I would have lost interest in Fido/BBS land a long time ago. It's the *only* thing keeping me around, because when this kind of discussion isn't happening, the discussions I'd rather not get involved in take over.
Which reminds me. A35 needs to be setup here soon. ;)
I see your maybe and raise you a definite. I did originally report...
"a sendmail script called for a 'fmail scan' which scanned _every_ message area: netmail, HMB & then JAM. It seemed to completely ignore the echomail.jam file except when it came time to delete it."
Wilfred, just a quick question have you enabled JAM for netmail bases
in FMail? This is a feature I'd really like to see as/when you're able
to look at it.
Thanks for the dev work you do :)
completely ignore the echomail.jam file except when
it came time to delete it."
I probably didn't pay enough attention, but you didn't say
'fmail scan -s' ! ;)
If you use the -s option or configure 'Scan always' in
FConfig, than that's the behaviour you get...
Oh, bugger... I found this in an exported config text, "Scan Always : Yes". Aww, I don't like saying "no" to things. It's so negative. My humble apologies, dear fellow. I will fix this schamozzle tomorrow
and give fmail scan a proper workout, along with some other evil plans
I have for FMail.
If I wasn't up to my armpits in EwwToob (YT), I'd do it now.
Priorities...
I will fix this schamozzle tomorrow and give fmailOk, keep us informed!
scan a proper workout, along with some other evil
plans I have for FMail.
If I wasn't up to my armpits in EwwToob (YT), I'd doIf you mean YouTube, yes I know, it's addictive! ;)
it now. Priorities...
09 Sep 17 20:56:14 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 - Scan--- 8< ---
09 Sep 17 20:56:14 FMAIL Echomail message, area FMAIL_HELP
09 Sep 17 20:56:14 FMAIL Update /opt/ftn/fido/outbound/02800180.hlo
09 Sep 17 20:56:14 FMAIL Mail bundle already going from 3:640/1384 to 3:640/384
09 Sep 17 20:56:14 FMAIL Netmail: 0, Personal: 0, Hudson: 0, JAMbase: 1 09 Sep 17 20:56:14 FMAIL Msgbase net: 0, echo: 1, dup: 0, bad: 0
09 Sep 17 20:56:14 FMAIL Scan Active: 0.162 sec.
If I didn't try things out and report any findings, I would have lost interest in Fido/BBS land a long time ago. It's the *only* thing
keeping me around, because when this kind of discussion isn't
happening, the discussions I'd rather not get involved in take over.
... Anyway, I have a tall tale to tell...area
This morning I modified GoldEd's config over to reading the FMail config rather than an Areas.Bbs file exported from it, after I found & re-enabled the GoldEd config switch to convert DOS paths to a Linux one in tosser
config files. (It took a little fine-tuning but in the end it worked.) So, after doing the right thing with the scan always FMail switch, I went through the motions of another post test. GoldEd created the echomail.jam file like this...manager
--- 8< ---
C:\opt\ftn\fido\msgbase\fmail_help 867
--- 8< ---
Which is fine since the FMail envar translation will convert it back to a Linux path. (I say back because FMail initially sucked in the Areas.Bbs file from CM II, _with_ Linux paths. And they stuck! FMail's area
has Linux paths!) So, running the sendmail.sh produced...
--- 8< ---
09 Sep 17 20:56:14 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 - Scan--- 8< ---
09 Sep 17 20:56:14 FMAIL Echomail message, area FMAIL_HELP
09 Sep 17 20:56:14 FMAIL Update /opt/ftn/fido/outbound/02800180.hlo
09 Sep 17 20:56:14 FMAIL Mail bundle already going from 3:640/1384 to
3:640/384 09 Sep 17 20:56:14 FMAIL Netmail: 0, Personal: 0, Hudson: 0,
JAMbase: 1 09 Sep 17 20:56:14 FMAIL Msgbase net: 0, echo: 1, dup: 0,
bad: 0 09 Sep 17 20:56:14 FMAIL Scan Active: 0.162 sec.
Neat, huh?
Very clear. However, the only reason it was scanned out is
because his FMail scanned _every_ area, rather than just what was
in the echomail.jam.
Nope. If I understood Paul correctly, it worked ok, scanning from echomail.jam!
Did you give Paul a compiled setup with the updated fmail.c you
gave me that fixed linux paths in echomail.jam?
Yes, it was freshly compiled. But it wasn't a debug version, so it
didn't contain the extra logging...
--- 8< ---
C:\opt\ftn\fido\msgbase\fmail_help 867
--- 8< ---
Which is fine since the FMail envar translation will convert it back
to a Linux path. (I say back because FMail initially sucked in the Areas.Bbs file from CM II, _with_ Linux paths. And they stuck!
FMail's area manager has Linux paths!) So, running the sendmail.sh produced...
--- 8< ---
09 Sep 17 20:56:14 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 - Scan--- 8< ---
09 Sep 17 20:56:14 FMAIL Echomail message, area FMAIL_HELP
09 Sep 17 20:56:14 FMAIL Update /opt/ftn/fido/outbound/02800180.hlo
09 Sep 17 20:56:14 FMAIL Mail bundle already going from 3:640/1384
to 3:640/384 09 Sep 17 20:56:14 FMAIL Netmail: 0, Personal: 0,
Hudson: 0, JAMbase: 1 09 Sep 17 20:56:14 FMAIL Msgbase net: 0,
echo: 1, dup: 0, bad: 0 09 Sep 17 20:56:14 FMAIL Scan Active: 0.162
sec.
Neat, huh? I shall admonish myself tomorrow for not saying "no"
enough times. :) Thank you for your kind assistance.
20 lashes with a wet noodle should do the trick! ;)<message>.
Nope. If I understood Paul correctly, it worked ok, scanning from
echomail.jam!
Ah. Well if that's the case, I completely missed a part of this conversation then.
Today I had set aside some play time with FMail, but I'm sort of hung upon
a little thing with the 'primary netmail' area. You know, the one not in any HMB base; it's the *.Msg area.
Just between you & me before anyone else notices: how does one bargain with or bribe FMail into exporting a FREQ netmail into the binkD
stream?
it's the *.Msg area.ahh... the mailer's playpen...
Just between you & me before anyone else notices: how does one
bargain with or bribe FMail into exporting a FREQ netmail into
the binkD stream?
you don't... the FREQs are completely different formats... this is where the nodelist comes into play and remote sites having proper FREQ flags defined... intelligent mailers like frontdoor do this as a matter of
fact because they know what format the remote needs... BSO mailers are generally not so intelligent...
what mailer are you using on the local end?
what mailer is running on the remote end?
Just between you & me before anyone else notices: how does one bargain with or bribe FMail into exporting a FREQ netmail into the binkD
stream?
FMail completely ignores a FREQ from me to my main node,
Just between you & me before anyone else notices: howYou can't.
does one bargain with or bribe FMail into exporting a
FREQ netmail into the binkD stream?
FMail completely ignores a FREQ from me to my mainThat's by design. Freq's are not really the domain of a
node,
mail processor/tosser.
A BSO mailer needs a .req file to send a file request to a
node.
So if you would pack a netmail with a freq flag into
a .pkt file nothing that you expect would happen except of
course the .pkt file would be send to the node. Where it
would be handled by the nodes tosser, and not by the
mailer or freq processor...
Just between you & me before anyone else notices: how does one
bargain with or bribe FMail into exporting a FREQ netmail into the
binkD stream?
You can't.
FMail completely ignores a FREQ from me to my main node,
That's by design. Freq's are not really the domain of a mail processor/tosser.
A BSO mailer needs a .req file to send a file request to a node. So if
you would pack a netmail with a freq flag into a .pkt file nothing
that you expect would happen except of course the .pkt file would be
send to the node. Where it would be handled by the nodes tosser, and
not by the mailer or freq processor...
You can't.
I am crushed. :(
That's by design. Freq's are not really the domain of a
mail processor/tosser.
You had better tell FTools then. It has a 'post' function sporting a '-r' switch (I wasn't using it... honest).
A BSO mailer needs a .req file to send a file request to a
node.
That's all the tosser needs to do in a BSO environment: parse the Subj field for FREQ-able filename(s), and create the .Req file for the intended system from the netmail. That .Req file is added to the .Flo file. The contents are the requested filename(s) at one per line.
Just between you & me before anyone else notices: how does one
bargain with or bribe FMail into exporting a FREQ netmail into the
binkD stream?
You can't.
one might be able to, though...
FMail completely ignores a FREQ from me to my main node,
That's by design. Freq's are not really the domain of a mail
processor/tosser.
right but it is the only thing in position to perform this feat...
right but it is the only thing in position to perform this
feat...
Isn't there software more geared towards file transfers in fidonet,
that can do this? Maybe something like allfix? (Just guessing)
You had better tell FTools then. It has a 'post' function
sporting a '-r' switch (I wasn't using it... honest).
That's about creating a filerequest message, not about handling it...
Ok it could be done, maybe in the pack function, or maybe in a seperate function. It doesn't seem all that hard... But it was never implemented by the original author, and never came up before in the 10 years I'm involved with the source code. I could put it on "the list", but it wouldn't be a high priority item...
You had better tell FTools then. It has a 'post' function
sporting a '-r' switch (I wasn't using it... honest).
That's about creating a filerequest message, not about handling
it...
Fascinating. That's what they mean by the term conundrum, I guess.
Why create something that cannot be handled by itself at a later
stage? Mmm...
Ok it could be done, maybe in the pack function, or maybe in a
seperate function. It doesn't seem all that hard... But it was
never implemented by the original author, and never came up
before in the 10 years I'm involved with the source code. I
could put it on "the list", but it wouldn't be a high priority
item...
Nice. Even at priority #99 it is still on 'the list'. :) Thank you.
You had better tell FTools then. It has a 'post' function
sporting a '-r' switch (I wasn't using it... honest).
Mmm...That's about creating a filerequest message, not about handling
it...
Fascinating. That's what they mean by the term conundrum, I guess. Why create something that cannot be handled by itself at a later stage?
Ok it could be done, maybe in the pack function, or maybe in a
seperate function. It doesn't seem all that hard... But it was never
implemented by the original author, and never came up before in the
10 years I'm involved with the source code. I could put it on "the
list", but it wouldn't be a high priority item...
Nice. Even at priority #99 it is still on 'the list'. :) Thank you.
Nice. Even at priority #99 it is still on 'the
list'. :) Thank you.
It's a coasy area of the list, with a lot of other wishes
which have been there a long time... ;)
Can I nominate another? I will anyway: has anyone commented on the paucity of output from 'ftools stat', yet? ;-)
I used to think that FastEcho did its thing rather well until I saw
the reports from CrashMail II. I can send you a copy of this
afternoon's report as an example, if you're interested...
FMail completely ignores a FREQ from me to my main node,
That's by design. Freq's are not really the domain of a mail
processor/tosser.
right but it is the only thing in position to perform this feat...
Isn't there software more geared towards file transfers in fidonet,
that can do this?
Maybe something like allfix? (Just guessing)
Can I nominate another?
I will anyway: has anyone commented on the paucity of output from
'ftools stat', yet? ;-)
I used to think that FastEcho did its thing rather well until I saw
the reports from CrashMail II. I can send you a copy of this
afternoon's report as an example, if you're interested...
And I learned a new English word: "paucity"...
You're the first.
I used to think that FastEcho did its thing rather well until I saw
the reports from CrashMail II. I can send you a copy of this
afternoon's report as an example, if you're interested...
I'm mildly interested. The ftools stat function is probably a remnant from the time fmail only supported the hudson message base. I never used it myself.
Aren't there external utils that can do stats on jam areas?
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,026 |
| Nodes: | 15 (0 / 15) |
| Uptime: | 28:43:23 |
| Calls: | 21 |
| Files: | 95,115 |
| D/L today: |
708 files (44,682K bytes) |
| Messages: | 295,718 |