• bug in sbbsecho when sending file attaches

    From mark lewis@VERT to digital man on Tuesday, July 30, 2019 00:18:30
    i seem to have found a bug in sbbsecho when sending file attaches outside of sbbs' known directories... i added an option to makenl today so that it does not generate msg files with the KILLSENT attribute... i ran a nodelist update with makenl that generated a new nodelist segment for transmission to my upstream *C...

    when fidoout.now was triggered and sbbsecho ran, it created a ?ut file with the
    message inside... the message has attributes 0111 and the ?lo file has ^/path/to/file/here.txt in it... if i'm reading the attributes correctly, that's

    Private, File Attached, Local

    the problem is that i do not want this attached file being deleted which is why
    i figured out how to get makenl to not create msgs with the KILLSENT bit turned
    on... i had thought that sbbsecho was creating the ?lo file with the ^ because of the KILLSENT bit but it appears that that was incorrect... so now i am at a loss as to why sbbsecho created the ?lo file with the ^ first character when the message did not have the KILLSENT bit set...


    ----- 00e501aa.dut -----
    pktdump rev 1.12 - Dump FidoNet Packets

    Opening 00e501aa.dut
    00e501aa.dut Packet Type 2+ (prod: 12FF, rev: 3.8) from 1:3634/12 to 1:229/426 Password: 'XXXXXXXX'
    0000003A
    00e501aa.dut 00003A Packed Message Type: 2 from 3634/12 to 229/426
    Attribute: 0111
    Date/Time: 29 Jul 19 16:20:38
    To : Coordinator
    From : MakeNL 3.5.1
    Subj :

    -start of message text-
    INTL 1:229/426 1:18/0
    MSGID: 1:18/0 00000002
    Via 1:3634/12 @20190729.203804.UTC SBBSecho 3.08-Linux r3.122
    -end of message text-
    000000E6
    ----- end -----


    ----- 00e501aa.dlo ----- ^/home/sbbs/fidonet/makenlng/fidonet/R18/master/r18s.210
    ----- end -----


    )\/(ark

    Once men turned their thinking over to machines in the hope that this would set
    them free. But that only permitted other men with machines to enslave them.
    ... Total is $1000. $10 for the upgrade, and $990 s/h.
    ---
    * Origin: (1:3634/12.73)
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to mark lewis on Monday, July 29, 2019 22:58:03
    Re: bug in sbbsecho when sending file attaches
    By: mark lewis to digital man on Mon Jul 29 2019 05:18 pm


    i seem to have found a bug in sbbsecho when sending file attaches outside of sbbs' known directories... i added an option to makenl today so that it does not generate msg files with the KILLSENT attribute... i ran a nodelist update with makenl that generated a new nodelist segment for transmission to my upstream *C...

    when fidoout.now was triggered and sbbsecho ran, it created a ?ut file with the message inside... the message has attributes 0111 and the ?lo file has ^/path/to/file/here.txt in it... if i'm reading the attributes correctly, that's

    Private, File Attached, Local

    the problem is that i do not want this attached file being deleted which is why i figured out how to get makenl to not create msgs with the KILLSENT bit turned on... i had thought that sbbsecho was creating the ?lo file with the ^ because of the KILLSENT bit but it appears that that was incorrect... so now i am at a loss as to why sbbsecho created the ?lo file with the ^ first character when the message did not have the KILLSENT bit set...

    Because that's what SBBSecho does with file attachments.

    Do you have a good reference for the KILLSENT attribute? The only description I've been able to find is from http://ftsc.org/docs/fsc-0081.001 ("A TYPE-3 Packet proposal") which says:

    KillSent Remove message after it has been sent.

    It doesn't mention the file attachment (if there is one), just the message.

    It wouldn't be difficult to make FLO-file attachment prefix more flexible, but are you sure that tying it to the KILLSENT attribute is correct? It seems that someone may want to have the netmail killed (deleted) after being sent, but *not* have a file attachment deleted.

    digital man

    This Is Spinal Tap quote #9:
    David St. Hubbins: I mean, it's not your job to be as confused as Nigel.
    Norco, CA WX: 88.0F, 49.0% humidity, 9 mph E wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From mark lewis@VERT to Digital Man on Thursday, August 01, 2019 03:01:12
    now that i have a little time, i'm coming back to this just to finish it off...


    On 2019 Jul 29 15:58:02, you wrote to me:

    the problem is that i do not want this attached file being deleted which
    is why i figured out how to get makenl to not create msgs with the
    KILLSENT bit turned on... i had thought that sbbsecho was creating the
    ?lo file with the ^ because of the KILLSENT bit but it appears that that
    was incorrect... so now i am at a loss as to why sbbsecho created the
    ?lo file with the ^ first character when the message did not have the
    KILLSENT bit set...

    Because that's what SBBSecho does with file attachments.

    ahh... i didn't think it was sbbsecho setting the "^" delete character on its own... i thought it was being done because of the killsent bit being set...

    Do you have a good reference for the KILLSENT attribute?

    i do not but there may be something in the original fido bbs documents or another FTN package... the best i can find is in the frontdoor and fastecho docs where they talk about if the bit is set, the message will be deleted... file attaches have generally always been left alone unless the KFS flag is set...

    i'm not going to try to add the Flag control line support to makenl, though... i had a hard enough time figuring out where and how to add the option to turn off the killsent bit :lol: it was defaulted on all the time in all messages but
    my feature addition now allows it to be set for each type of message that makenl creates... notify received, notify error, and submittal messages which the last carries the new segment to the upstream *C...

    The only description I've been able to find is from http://ftsc.org/docs/fsc-0081.001 ("A TYPE-3 Packet proposal") which
    says:

    KillSent Remove message after it has been sent.

    It doesn't mention the file attachment (if there is one), just the
    message.

    yeah... just the message should be deleted with the killsent bit... not any attached files...

    and yeah, that is one of the Type 3 specs... i helped with them way back in the
    day when NET_DEV was much busier than it is today... they never went anywhere... there were several of them and also Type 10, too... IIRC, there is a funny thing about the Type 10 name... funny being that it is a play on Type 2... 10 being binary instead of decimal ;)

    It wouldn't be difficult to make FLO-file attachment prefix more
    flexible, but are you sure that tying it to the KILLSENT attribute is correct?

    ideally, the file attachment will be left alone even if the message is set to be killed... imagine attaching files from your files areas to someone and later
    finding the files have been deleted... similar thing to this situation except mine is my net and region nodelist segments which i don't want deleted...

    one of the reasons for this is automating the makenl process... if there's no changes, then no new segment is created... it needs the old segment to compare to, AFAIK... if it is deleted, there's nothing to compare to and a new segment is created and sent...

    yes, the automation could be triggered by a new segment coming in but then we may be sending more than one per day in some cases and that may not be a good thing... easier to just run the makenl event daily at a certain time and let is
    decide to send the segment if one is generated or not...

    It seems that someone may want to have the netmail killed (deleted)
    after being sent, but *not* have a file attachment deleted.

    exactly... in my case i modified makenl to not apply the killsent bit but the file was still deleted by the mailer which is when i came here and wrote about it... i really didn't expect it to be sbbsecho setting the "^" delete option in
    the flo file...

    you and i have briefly talked about the KFS (KillFileSent) flag in the flags line and that may be desirable at some point but for now, let's just leave things as they are... they're working a lot better and other sbbs using *Cs won't need to do any special dances to keep their segments when they get generated...

    i really do appreciate you taking the time to alter the behavior of sbbsecho for this situation... thanks again for fixing this!

    )\/(ark

    Once men turned their thinking over to machines in the hope that this would set
    them free. But that only permitted other men with machines to enslave them.
    ... If at first you fricassee, fry, fry again.
    ---
    * Origin: (1:3634/12.73)
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net