Hello All,

Last question for tonight, and maybe I'll get an answer by tomorrow.

So I have everything setup, including in my node manager for my link (myself) I
have compression set to NONE. Also, in my compression/decompression settings I only have ZIP setup, and set as default (even though this shouldn't matter since my link is set to no compression).

That said, when I run "fmail scan -A -E -N -J -S" (even though I really don't need all that), I get:

Retrying to compress outgoing mailpacket(s)
DEBUG packArc: file /home/axisd/fido/outbound/00000001.qqq 1:154/10.1 -> 1:154/10 outStatus:2

There the .QQQ file sits with my two messages in my outbound directory. I'm lost.

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

On 2017 Aug 08 20:20:06, you wrote to All:

Retrying to compress outgoing mailpacket(s)
DEBUG packArc: file /home/axisd/fido/outbound/00000001.qqq 1:154/10.1 -> 1:154/10 outStatus:2

There the .QQQ file sits with my two messages in my outbound directory.

I'm

lost.

the .qqq file is a PKT... they are generally built in a temp directory and then
renamed and moved to your outbound... but wait, it is in your outbound already so just needs the rename to PKT or ?UT... it PKT then a .?LO file should also be created to point to it...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I'll have two brains on drugs with sausage, grits, toast and coffee.
---
* Origin: (1:3634/12.73)

Hi Nicholas,

On 08 Aug 17 20:20, Nicholas Boel wrote to All:
about: "Argh..":

Last question for tonight, and maybe I'll get an answer by tomorrow.

It's received here at 3:26 in the middle of the night. ;)

So I have everything setup, including in my node manager for my link (myself) I have compression set to NONE. Also, in my compression/decompression settings I only have ZIP setup, and set as default (even though this shouldn't matter since my link is set to no compression).

Indeed.

That said, when I run "fmail scan -A -E -N -J -S" (even though I
really don't need all that), I get:

So you red the docs? ;)
(I don't use any options on my "regular" scan command)

-E and -N are mutually exclusive. I don't know what happens when you use both at the same time.

Retrying to compress outgoing mailpacket(s)
DEBUG packArc: file /home/axisd/fido/outbound/00000001.qqq 1:154/10.1 -> 1:154/10 outStatus:2

Hey you build a debug version. ;)
outStatus:2 just means the node has "crash" status.

This is logged at the beginning of the packArc function. It's what happens afterwards that is the interesting part...

There the .QQQ file sits with my two messages in my outbound
directory. I'm lost.

.qqq files are temporary pkt files that are left when something went wrong scanning/packing. And are retried the next time fmail is run.

Wilfred.

--- FMail-W32 2.0.1.4
* Origin: point@work (2:280/464.112)

Hi mark,

On 09 Aug 17 01:12, mark lewis wrote to Nicholas Boel:
about: "Argh..":

There the .QQQ file sits with my two messages in my outbound
directory. I'm lost.

the .qqq file is a PKT... they are generally built in a temp directory and then renamed and moved to your outbound...

FMail doesn't use a temporary directory.

but wait, it is in your outbound already so just needs the rename to
PKT or ?UT... it PKT then a .?LO file should also be created to point
to it...

That should happen automatically by FMail, if everything is right...

Wilfred.

--- FMail-W32 2.0.1.4
* Origin: point@work (2:280/464.112)

On 2017 Aug 09 09:04:10, you wrote to me:

There the .QQQ file sits with my two messages in my outbound
directory. I'm lost.

the .qqq file is a PKT... they are generally built in a temp directory
and then renamed and moved to your outbound...

FMail doesn't use a temporary directory.

so it does all its work in the current directory or the directory in which the executable is located?

but wait, it is in your outbound already so just needs the rename to
PKT or ?UT... it PKT then a .?LO file should also be created to point
to it...

That should happen automatically by FMail, if everything is right...

yup...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Everyone is ignorant... only on different subjects.
---
* Origin: (1:3634/12.73)

Hello mark,

On Wed Aug 09 2017 01:12:16, mark lewis wrote to Nicholas Boel:

There the .QQQ file sits with my two messages in my outbound
directory. I'm lost.

the .qqq file is a PKT... they are generally built in a temp directory
and then renamed and moved to your outbound... but wait, it is in your outbound already so just needs the rename to PKT or ?UT... it PKT then
a .?LO file should also be created to point to it...

Thanks, but nothing was helpful here. ;)

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hi mark,

On 09 Aug 17 14:42, mark lewis wrote to Wilfred van Velzen:
about: "Argh..":

the .qqq file is a PKT... they are generally built in a temp
directory and then renamed and moved to your outbound...

FMail doesn't use a temporary directory.

so it does all its work in the current directory or the directory in which the executable is located?

I didn't do an extensive search in the source about this, but afaik fmail doesn't use the CWD. And the executable directory is used (mainly for the config files) if you don't specify a "working" directory through the FMAIL environment variable. But it doesn't use that for creating pkt files. They are created directly in the outbound directory...

Wilfred.

--- FMail-W32 2.0.1.4
* Origin: point@work (2:280/464.112)

On 2017 Aug 10 08:58:42, you wrote to me:

the .qqq file is a PKT... they are generally built in a temp
directory and then renamed and moved to your outbound...

FMail doesn't use a temporary directory.

so it does all its work in the current directory or the directory in
which the executable is located?

I didn't do an extensive search in the source about this, but afaik
fmail doesn't use the CWD. And the executable directory is used
(mainly for the config files) if you don't specify a "working"
directory through the FMAIL environment variable. But it doesn't use
that for creating pkt files. They are created directly in the outbound directory...

i was wondering about that... with the .qqq extension, that should be OK but then the question comes about if FMail supports fileboxes and if so, where does
it create the .qqq files? anything in a filebox is sent to the system assigned to that box... i've got one link, now, that is insisting on sharing one mailer with two different nodes and routing is broken such that they're sending my system .out files for their other system where they are trying to route the mail to... it is a mess and i'm not sure what else to say to get them to change
their setup and use two binkd installs with different ports, directories and fileboxes... it should be really easy to do with one binary and two different config files but... back to the point, if something tries to create a temp file
in the filebox and then rename it to whatever its proper name should be, binkd may have already sent it off since there's no semaphores to tell binkd to not process that filebox at that point in time...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... The more boundless your vision, the more real you are.
---
* Origin: (1:3634/12.73)

Hi mark,

On 2017-08-10 15:14:18, you wrote to me:

I didn't do an extensive search in the source about this, but afaik
fmail doesn't use the CWD. And the executable directory is used
(mainly for the config files) if you don't specify a "working"
directory through the FMAIL environment variable. But it doesn't use
that for creating pkt files. They are created directly in the outbound
directory...

i was wondering about that... with the .qqq extension, that should be OK but then the question comes about if FMail supports fileboxes and if so, where does it create the .qqq files? anything in a filebox is sent to the system assigned to that box...

They are created in the regular outbound, as all the files are, and when they are finished, they are renamed/moved to the filebox directory.

back to the point, if something tries to create a temp file in the
filebox and then rename it to whatever its proper name should be,
binkd may have already sent it off since there's no semaphores to tell binkd to not process that filebox at that point in time...

I'm aware of that, and the original author of FMail apparently too, because it's done in a correct way. ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.17-B20170711
* Origin: FMail development HQ (2:280/464)

Hi! mark,

On 08/11/2017 05:14 AM, you wrote to Wilfred van Velzen:

binkd may have already sent it off since there's no semaphores to tell binkd to not process that filebox at that point in time...

Interesting, 'coz that's the problem I solved with using Radius on my other node... by enforcing a "u,Txy" nodelist override for a node while my DOS was trying to simply _move_ half a GiB of files to a filebox. Fortunately only once
a day.

Nevertheless, can't binkD be *stalled* for a node by utilizing *.?sy flags?

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)

On 2017 Aug 11 08:10:26, you wrote to me:

binkd may have already sent it off since there's no semaphores to
tell binkd to not process that filebox at that point in time...

Interesting, 'coz that's the problem I solved with using Radius on my other node... by enforcing a "u,Txy" nodelist override for a node
while my DOS was trying to simply _move_ half a GiB of files to a
filebox. Fortunately only once a day.

radius and derivitives have a bug dealing with U,Txy flags... specifically that
they should not be UFlags in this day in time...

Nevertheless, can't binkD be *stalled* for a node by utilizing *.?sy flags?

that is one possible solution... one would need to look at traditional binkleyterm utilities to see what they did for things like this... SOB and SOSOB are two utils that may provide an answer... too bad that so many binkleyterm related tools are simply no longer available and/or are otherwise forgotten in the mists of time :(

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... My Canada includes: 3 downs, 110 yards and an import rule!
---
* Origin: (1:3634/12.73)

Hi! mark,

On 08/11/2017 12:48 PM, you wrote:

radius and derivitives have a bug dealing with U,Txy flags...
specifically that they should not be UFlags in this day in time...

That is an interesting POV on a standard that was in widespread use for over a decade, and which was rescinded/modified to fix a clerical fault in FTSC administrative requirements. Fortunately it is not binding on individual system override settings.

Nevertheless, can't binkD be *stalled* for a node by utilizing *.?sy
flags?

that is one possible solution... one would need to look at
traditional binkleyterm utilities to see what they did for things
like this... SOB and SOSOB are two utils that may provide an
answer... too bad that so many binkleyterm related tools are simply
no longer available and/or are otherwise forgotten in the mists of
time :(

Dude, we're talking binkD only. Pavel Gulchouck (2:463/68) wrote in the binkD echo back on Mon, 25 Jan 16...

"*.csy are used a similar way to *.bsy but they set on start calling node, before handshake. It prevents simultaneous calls to the remote node by several binkd processes."

That is _the_ solution in binkD usage canon. I just don't know of anyone who uses it (.csy)... yet. Nudge, nudge. ;-)

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)

Hi Paul,

On 11 Aug 17 08:10, Paul Quinn wrote to mark lewis:
about: "Argh..":

while my DOS was trying to simply _move_ half a GiB of files to a
filebox. Fortunately only once a day.

If you have to do that, create the files in a temporary directory on the same drive as the filebox. And when the files are ready, do a rename to the filebox dir. Rename is an atomic operation on most os's afaik. So binkd won't see any "half" written files.

Nevertheless, can't binkD be *stalled* for a node by utilizing *.?sy flags?

The best way, of course, is to use the normal outbound directory in the propper
way for this, and not use a filebox. ;)

Wilfred.

--- FMail-W32 2.0.1.4
* Origin: point@work (2:280/464.112)

Hi! Wilfred,

On Fri, 11 Aug 17, you wrote to me:

while my DOS was trying to simply _move_ half a GiB
of files to a filebox. Fortunately only once a
day.

If you have to do that, create the files in a temporary
directory on the same drive as the filebox. And when the
files are ready, do a rename to the filebox dir. Rename is
an atomic operation on most os's afaik. So binkd won't see
any "half" written files.

The files are created elsewhere and are then moved. Are you saying that the filebox reference in the binkD.cfg be updated to the temporary directory? ;-)
No, I'm sure you're not. I'm guessing that a move is a kind of rename in the underlying DOS (in fact MS-DOS 7.1).

It just takes enough time to be a problem, where the mailer wants to start a session while the files are being created by ARJ (whose replcement with ZIP was
another project slipped in favour of Fmail), or indeed even being moved. The affected node (a local point system) is only effectively undialable by the mailer for a half hour block (the smallest time period available under the Txy standard); it's still available for the remaining 23.5 hours/day.

Nevertheless, can't binkD be *stalled* for a node by
utilizing *.?sy flags?

The best way, of course, is to use the normal outbound
directory in the propper way for this, and not use a
filebox. ;)

I use both but not at the same time for the same nodes, of course. The fileboxes support a separate _household_ network riding on the back of Fido I call a system of StarGates. What goes in one comes out at another someplace, just like StarGates in the TV series operate. :)

Oh, and I thought that you might have been hinting to mark that Fmail uses binkD semaphores (*.csy) while creating mail bundles for a node. Or maybe Fmail could in the future?

Cheers,
Paul.

--- Paul's Win98SE VirtualBox
* Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)

Hi Paul,

On 2017-08-11 22:30:00, you wrote to me:

If you have to do that, create the files in a temporary
directory on the same drive as the filebox. And when the
files are ready, do a rename to the filebox dir. Rename is
an atomic operation on most os's afaik. So binkd won't see
any "half" written files.

The files are created elsewhere and are then moved. Are you saying that the filebox reference in the binkD.cfg be updated to the temporary directory? ;-) No, I'm sure you're not. I'm guessing that a move is a kind of rename in the underlying DOS (in fact MS-DOS 7.1).

Move can be a rename if it's on the same drive, then it's fast

It just takes enough time to be a problem, where the mailer wants to
start a session while the files are being created by ARJ (whose
replcement with ZIP was another project slipped in favour of Fmail),
or indeed even being moved.

Then it probably isn't a rename.

The best way, of course, is to use the normal outbound
directory in the propper way for this, and not use a
filebox. ;)

I use both but not at the same time for the same nodes, of course. The fileboxes support a separate _household_ network riding on the back of

Fido

I call a system of StarGates. What goes in one comes out at another someplace, just like StarGates in the TV series operate. :)

I have also configured fileboxes for some nodes in my binkd.config, as an easy way to dump files to them. But I have configured them wiht 'h' (hold). So binkd
doesn't touch these files until a "regular" connection is made to the system. That way a copy/move to the filebox can take some time, without being it a problem, because binkd doesn't start transmitting them right away.

Oh, and I thought that you might have been hinting to mark that Fmail
uses binkD semaphores (*.csy) while creating mail bundles for a node.
Or maybe Fmail could in the future?

Of course fmail uses bso style semaphore files, but just the *.bsy ones, which is sufficient...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.17-B20170711
* Origin: FMail development HQ (2:280/464)

On 2017 Aug 11 17:08:58, you wrote to me:

radius and derivitives have a bug dealing with U,Txy flags...
specifically that they should not be UFlags in this day in time...

That is an interesting POV on a standard that was in widespread use for over a decade, and which was rescinded/modified to fix a clerical fault in FTSC administrative requirements.

what??? what i'm saying is that U,Txy flags should be just Txy with no U... the
problem with radius and others is/was that they insisted on the U or they would
not properly process the flag, IIRC... Txy hasn't been a user flag since it was
approved many years back after it went through a testing period as a U flag...

Fortunately it is not binding on individual system override settings.

there is that...

Nevertheless, can't binkD be *stalled* for a node by utilizing *.?sy
flags?

that is one possible solution... one would need to look at
traditional binkleyterm utilities to see what they did for things
like this... SOB and SOSOB are two utils that may provide an

oops... that should be BONK and SOB (Son of BONK)...

answer... too bad that so many binkleyterm related tools are simply
no longer available and/or are otherwise forgotten in the mists of
time :(

Dude, we're talking binkD only.

it is a BSO mailer and should follow standard BSO ops... BONK and SOB can be used by all BSO systems...

Pavel Gulchouck (2:463/68) wrote in the binkD echo back on Mon, 25 Jan 16...

"*.csy are used a similar way to *.bsy but they set on start calling
node, before handshake. It prevents simultaneous calls to the remote
node by several binkd processes."

yeah... using a BSY semaphore is fine... that's what i was saying about looking
at BONK and SOB to see what they do when they are processing existing waiting outbound mail... BONK and SOB are also used to "qualify" mail for sending at specific times in a similar manner to frontdoor's schedule qualifier stuff for mail... in other words, the files are named different so that the mail cnn't see them but at, say, 0200, BONK or SOB are run and will see that you want to send to system x:y/z so it will rename those files for that system so the mailer can see them now... actually scheduling and qualifying outbound mail for
sending... unfortunately if x:y/z polls you before their mail is qualified, they won't get it since the mailer cannot see it due to the file names... that's different than frontdoor which handles it all internally and does provide unqualified mail to polling systems...

yeah yeah yeah, i know but i cannot help really really really liking the intelligence that frontdoor has built in compared to the rocks and stones that binkleyterm and most of its derivitives plod along with...

That is _the_ solution in binkD usage canon. I just don't know of
anyone who uses it (.csy)... yet. Nudge, nudge. ;-)

the only BSO stuff i currently use is mainly a poll file creator written in 4DOS and bash... i couldn't get the 4OS2 side to process the script properly...
something about missing functions and other functions working differently... anyway, the script just touches or creates ?LO semaphores once it validates the
address the poll is for...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Live a little - butter both sides of the bread.
---
* Origin: (1:3634/12.73)

On 2017 Aug 11 13:35:54, Wilfred van Velzen wrote to you:

while my DOS was trying to simply _move_ half a GiB of files to a
filebox. Fortunately only once a day.

If you have to do that, create the files in a temporary directory on
the same drive as the filebox. And when the files are ready, do a
rename to the filebox dir. Rename is an atomic operation on most os's afaik. So binkd won't see any "half" written files.

and because they're on the same partition, the OS can simply rename them right into the destination directory... if they are on a different partition, they have to be physically copied and that's where problems can happen when the mailer sees them before the copy is complete...

Nevertheless, can't binkD be *stalled* for a node by utilizing *.?sy
flags?

The best way, of course, is to use the normal outbound directory in
the propper way for this, and not use a filebox. ;)

either way, one must still use something to signal to the mailer that something
is happening for that remote address... using a BSY file should be all that's needed... with binkd, one might want to also create the afore mentioned csy file, too... the file name, itself, is the same as used for ?LO and ?UT files...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Thoughtfulness is to friendship as sunshine is to a garden.
---
* Origin: (1:3634/12.73)

Hi! mark,

On 08/12/2017 06:11 AM, you wrote:

like this... SOB and SOSOB are two utils that may provide an

oops... that should be BONK and SOB (Son of BONK)...

I knew that.

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)

On 2017 Aug 12 07:48:32, you wrote to me:

like this... SOB and SOSOB are two utils that may provide an

oops... that should be BONK and SOB (Son of BONK)...

I knew that.

i thought you did... i remember talking with you and a few others about them some time back :)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... The graveyards are full of indispensable men.
---
* Origin: (1:3634/12.73)

Hi! mark,

On Fri, 11 Aug 17, you wrote to me:

oops... that should be BONK and SOB (Son of BONK)...

I knew that.

i thought you did... i remember talking with you and a few
others about them some time back :)

Even better: I still use BONK, and sometimes BinkleyTerm... just to occasionally keep tabs on Radius. If I said that they use some common voodoo, you would not be hearing something new.

Cheers,
Paul.

--- Paul's Win98SE VirtualBox
* Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)