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)