I'll make a new version for you later tonight (tomorrow for you), or
later this week. If you don't hear from me in a couple of days,
please remind me. ;)
No problem. I have tobacco. Waiting without tobacco is an unbearable bore. :)
I just did a recompile, and didn't test anything, except starting it...
Nothing amiss with your system(s), mate. Someone regurgitated an old
post of yours in a file announcement echo using a 1:15/0 origin line
over the top (really under) one of yours.
Lovely weather here. 5th day of spring & temp maxed at 30C! Summer may be warm-ish. ;-)
I just did a recompile, and didn't test anything, except starting
it...
Copy received. Thanks, muchly. Ooh, ooh... now I have to do something... oh, no...! (It complains as usual, on this old netbook[v2.6 Linux].) Gotta get out of bed... :)
Copy received. Thanks, muchly. Ooh, ooh... now I
have to do something... oh, no...! (It complains as
usual, on this old netbook[v2.6 Linux].) Gotta get
out of bed... :)
I'll stay tuned! ;)
Ooh, ooh... now I have to do something... oh, no...!
I'll stay tuned! ;)
Ooh, ooh... now I have to do something... oh, no...!
I'll stay tuned! ;)
Well, I managed to screw up even some of the simplest things but eventually got something like a normal echomail scan out...
GoldEd created the expected echomail.jam file, containing...
--- 8< ---
/opt/ftn/fido/msgbase/fec1e5dd 8020
--- 8< ---
In the areas.bbs file that file is identified as...
--- 8< ---
!/opt/ftn/fido/msgbase/fec1e5dd WIN95 3:640/384
--- 8< ---
Then 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.
This was kinda awkward so I re-ran the same actions. Same result. Oops. ;-)
There must have been something else that I missed? Do you have any suggestions, please?
GoldEd created the expected echomail.jam file, containing...
/opt/ftn/fido/msgbase/fec1e5dd 8020
--- 8< ---
Is that the name of the jam area filenames (without the extensions)?
Mine have more readable names. For instance when I reply to this message echomail.jam contains:
/home/fido/jam/fido/fmailhelp 998
In the areas.bbs file that file is identified as...
!/opt/ftn/fido/msgbase/fec1e5dd WIN95 3:640/384
--- 8< ---
Do you run Golded and the sendmail script as the same linux user? Is
that user also the owner of the echomail.jam file and the jam area files?
What does the log say?
07 Sep 17 12:15:14 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 - Scan[ ...trimmed... ]
07 Sep 17 12:15:14 FMAIL Scanning JAM area 0: ABLED
07 Sep 17 12:15:15 FMAIL Scanning JAM area 172: WIN95--- 8< ---
07 Sep 17 12:15:15 FMAIL Echomail message, area WIN95
07 Sep 17 12:15:15 FMAIL Scanning JAM area 173: WINDOWS
07 Sep 17 12:15:15 FMAIL Scanning JAM area 174: WWIV
07 Sep 17 12:15:15 FMAIL Scanning JAM area 175: ZEC
07 Sep 17 12:15:15 FMAIL Scanning JAM area 176: ZONE3_SYSOP
07 Sep 17 12:15:15 FMAIL Scanning JAM area 177: ZONE3_TECH
07 Sep 17 12:15:15 FMAIL Update /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.
What does the log say?
--- 8< ---
07 Sep 17 12:15:14 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 - Scan[ ...trimmed... ]
07 Sep 17 12:15:14 FMAIL Scanning JAM area 0: ABLED
07 Sep 17 12:15:15 FMAIL Scanning JAM area 172: WIN95--- 8< ---
07 Sep 17 12:15:15 FMAIL Echomail message, area WIN95
07 Sep 17 12:15:15 FMAIL Scanning JAM area 173: WINDOWS
07 Sep 17 12:15:15 FMAIL Scanning JAM area 174: WWIV
07 Sep 17 12:15:15 FMAIL Scanning JAM area 175: ZEC
07 Sep 17 12:15:15 FMAIL Scanning JAM area 176: ZONE3_SYSOP
07 Sep 17 12:15:15 FMAIL Scanning JAM area 177: ZONE3_TECH
07 Sep 17 12:15:15 FMAIL Update /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.
The terminal screen says things about checking netmail & HMB, and then JAM areas. Nothing about the echomail.jam file at all.
The terminal screen says things about checking
netmail & HMB, and then JAM areas. Nothing about the
echomail.jam file at all.
Maybe the loging/printing isn't perfect, but this all
seems fine. Have you checked if the mail arrived at it's
destination (3:640/384) ?
If you are not certain you can have FMail make backups of
outgoing .pkt files by specifying a "Outgoing backup"
directory in FConfig. So you have a way of checking what's
produced without it disappearing because of your mailer
(or other processes) doing their jobs...
Maybe the loging/printing isn't perfect, but this all
seems fine. Have you checked if the mail arrived at it's
destination (3:640/384) ?
Maybe so. They were only test posts within a 'sandbox'. OTOH, I've just now checked the mail bundle with David Nugent's 'InspectA' util, and found the posts were written properly.
Even the TZUTC values were correct.
If you are not certain you can have FMail make backups of
outgoing .pkt files by specifying a "Outgoing backup"
directory in FConfig. So you have a way of checking what's
produced without it disappearing because of your mailer
(or other processes) doing their jobs...
I used to when I first started toying with FMail/lnx, but soon turned that off. They're effectively being backup up for the duration of the testing phase by not being sent anywhere. They're boxed in as if "lab rats". :)
GoldEd created the expected echomail.jam file, containing...
/opt/ftn/fido/msgbase/fec1e5dd 8020
In the areas.bbs file that file is identified as...
!/opt/ftn/fido/msgbase/fec1e5dd WIN95 3:640/384
--- 8< ---
07 Sep 17 12:15:14 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 -[ ...trimmed... ]
Scan 07 Sep 17 12:15:14 FMAIL Scanning JAM area 0: ABLED
07 Sep 17 12:15:15 FMAIL Scanning JAM area 172: WIN95--- 8< ---
07 Sep 17 12:15:15 FMAIL Echomail message, area WIN95
07 Sep 17 12:15:15 FMAIL Scanning JAM area 173: WINDOWS
07 Sep 17 12:15:15 FMAIL Scanning JAM area 174: WWIV
07 Sep 17 12:15:15 FMAIL Scanning JAM area 175: ZEC
07 Sep 17 12:15:15 FMAIL Scanning JAM area 176: ZONE3_SYSOP
07 Sep 17 12:15:15 FMAIL Scanning JAM area 177: ZONE3_TECH
07 Sep 17 12:15:15 FMAIL Update
/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.
The terminal screen says things about checking netmail & HMB, and then
JAM areas. Nothing about the echomail.jam file at all.
GoldEd created the expected echomail.jam file, containing...
/opt/ftn/fido/msgbase/fec1e5dd 8020
The above seems like a MSGID or a computed packet naming scheme, not an areatag. Is the echotag actually fec1e5dd? Also, is 8020 the number of your message in the message base?
In the areas.bbs file that file is identified as...
!/opt/ftn/fido/msgbase/fec1e5dd WIN95 3:640/384
--- 8< ---
07 Sep 17 12:15:14 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 -
--- 8< ---
This log snippet doesn't mention anything about area "fec1e5dd". But it does mention "WIN95". Something seems odd there, like your echomail.jam should read:
/opt/ftn/fido/msgbase/win95 8020
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. ;)
/opt/ftn/fido/msgbase/fec1e5dd 8020
Also, is 8020 the number of your message in the message base?
/opt/ftn/fido/msgbase/fec1e5dd 8020
The above seems like a MSGID or a computed packet naming scheme,
not an areatag. Is the echotag actually fec1e5dd? Also, is 8020
the number of your message in the message base?
No bout-a-doubt it. I'm with you on this. It does and probably uses
the same hashing code... in FastEcho (FE). It's originally an auto-created FE echomail base filename generated by using a hash
value. (While browsing logfiles, I narrowed it down last night to sometime during the week 14-20 December 1997.) It is how FE does that sort of thing.
In the areas.bbs file that file is identified as...
!/opt/ftn/fido/msgbase/fec1e5dd WIN95 3:640/384
This is the important bit... ^^^^ It's where the translation you're looking for occurs, and also most importantly, is in FMail's
area manager also. The areas.bbs is only used by GoldEd, and is the
only format quotable in echomail taking into account FMail's config
files are binary types.
This log snippet doesn't mention anything about area "fec1e5dd".
But it does mention "WIN95". Something seems odd there, like your
echomail.jam should read: /opt/ftn/fido/msgbase/win95 8020
For most of the echo areas that is true; there is a very small number
of areas cloned from my old FE config. Your average echomail.jam
deals in echo base path+filename and message number, only. No area
tags.
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-)
It is how FE does that sort of thing.
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.
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?
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 fo your co-operation". 8-)
Yeah, or "Go get me a beer first, then we'll talk!"
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,044 |
Nodes: | 15 (0 / 15) |
Uptime: | 54:43:01 |
Calls: | 236,099 |
Calls today: | 1 |
Files: | 60,370 |
D/L today: |
55 files (55,564K bytes) |
Messages: | 289,326 |