• Argh..

    From Nicholas Boel@1:154/10 to All on Tue Aug 8 20:20:06 2017
    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)
  • From mark lewis@1:3634/12.73 to Nicholas Boel on Wed Aug 9 01:12:16 2017

    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)
  • From Wilfred van Velzen@2:280/464.112 to Nicholas Boel on Wed Aug 9 09:03:06 2017
    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)
  • From Wilfred van Velzen@2:280/464.112 to mark lewis on Wed Aug 9 09:04:11 2017
    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)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Wed Aug 9 14:42:48 2017
    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)
  • From Nicholas Boel@1:154/10 to mark lewis on Wed Aug 9 17:51:24 2017
    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)
  • From Wilfred van Velzen@2:280/464.112 to mark lewis on Thu Aug 10 08:58:43 2017
    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)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Thu Aug 10 15:14:18 2017
    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)
  • From Wilfred van Velzen@2:280/464 to mark lewis on Thu Aug 10 23:27:09 2017
    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)
  • From Paul Quinn@3:640/1384 to mark lewis on Fri Aug 11 08:10:27 2017
    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)
  • From mark lewis@1:3634/12.73 to Paul Quinn on Thu Aug 10 22:48:04 2017

    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)
  • From Paul Quinn@3:640/1384 to mark lewis on Fri Aug 11 17:08:59 2017
    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)
  • From Wilfred van Velzen@2:280/464.112 to Paul Quinn on Fri Aug 11 13:35:55 2017
    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)
  • From Paul Quinn@3:640/384 to Wilfred Van Velzen on Fri Aug 11 22:30:00 2017
    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)
  • From Wilfred van Velzen@2:280/464 to Paul Quinn on Fri Aug 11 15:27:03 2017
    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)
  • From mark lewis@1:3634/12.73 to Paul Quinn on Fri Aug 11 16:11:32 2017

    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)
  • From mark lewis@1:3634/12.73 to Paul Quinn on Fri Aug 11 16:26:12 2017

    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)
  • From Paul Quinn@3:640/1384 to mark lewis on Sat Aug 12 07:48:33 2017
    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)
  • From mark lewis@1:3634/12.73 to Paul Quinn on Fri Aug 11 23:06:02 2017
    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)
  • From Paul Quinn@3:640/384 to Mark Lewis on Sat Aug 12 16:26:00 2017
    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)