open https://gitlab.synchro.net/main/sbbs/-/issues/343

When Tickit processes incoming files for a downlink with a status of HOLD in the (echocfg) LINKED NODE section as well as a POLL=NO under BinkP Settings. The link also has a blank BinkP HOST entry. BinkIt still tries to send the files. SBBSECHO creates proper OUTBOUND *.hlo files for echomail, but TickIT creates *.flo files for the same node for any files to be sent. This is the same whether it's a regular node or a point.When the node polls IN, the issue goes away until the next incoming *.TIC file if processed.Ray W6RAY
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/343#note_2288

can confirm... i see this even with older pre-git TickIt... it is a defect i did not notice when i was working on TickIt back in 2018-2019... TickIt should create/update the proper flo files according to the node's status in sbbsecho.ini...
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/343#note_2304

Now I see it's trying to use the f23.n213.z1.binkp.net to send the waiting mail.Feb 22 15:34:26 bbs Synchronet: evnt BINKIT Running timed event: BINKITFeb 22 15:34:26 bbs Synchronet: evnt BINKIT BinkIT/2.41 invoked with options:Feb 22 15:34:27 bbs Synchronet: evnt BINKIT Attempting callout for 1:214/23@fidonet, file: /bbs/mail/out/fido/00d60017.floFeb 22 15:34:27 bbs Synchronet: evnt BINKIT JSBinkP/4 callout to 1:214/23@fidonet startedFeb 22 15:34:28 bbs Synchronet: evnt BINKIT Connecting to 1:214/23@fidonet at undefinedf23.n214.z1.binkp.net:24554Feb 22 15:34:48 bbs Synchronet: evnt BINKIT Connection to undefinedf23.n214.z1.binkp.net:24554 failed (Error: Name or service not known).It really isn't hurting anything, but it helps fill up the log file.
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/343#note_4713

It doesn't look like anything has been done yet. I am hopeful that it soon will.

Lately, since binkit is still trying to call out to the nodes whose addresses are set to hold (tickit is creating .flo files instead of .hlo files), and creating .bsy files when it does, the inbound area fills up and tickit doesn't run to process incoming .tic files. After deleting the .bsy file(s), tickit will run as it should. Before it does, I append the corresponding .flo to the .hlo file manually.

Not being a programmer, I have no idea where to look in the code to attempt to repair it. I am hopeful that someone who can, will correct this. In the meantime, I will have to return to Husky's htick. I like that binkit, tickit, etc., are all integrated and requires fewer configuration files.

Thanks!!
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/343#note_4727

FWIW: binkit is doing right when it tries to deliver flo, clo, and dlo files to a remote set as hold... binkd does the same... this allows binkit/binkd to deliver some mail while the remote node has to connect inbound to pick up whatever traffic is waiting on hold... for example, maybe you don't want to deliver some huge file(s) but you still want to deliver mail...

the fix to create or append to existing hlo (and dlo or clo) file(s) is needed in tickit... i thought i saw a commit long ago from someone else that did fix it but i cannot locate that commit... i've been thinking for the last months that i needed to find it and backport it to my old pre-git version... with all the changes since the last time i updated before the move to git, i don't know if routine(s) to look that up exist, if they are the same as they were, or need to be created...

in any case, a quick look at my copy of the old code shows that at the end of "function forward_tic(tic)" flo is assumed and no lookup for flo type is done at all... look for comment "// Append to FLO file..."...

there probably should also be a timeout abort just higher in the "// Create bsy file..." section... especially if multiple tickits are being fired and running at the same time... looks like a possible race condition with other instances and may be where your multiple bsy files are coming from... perhaps tickit should maintain a "running" semaphore so only one instance can be executed at a time? idk and it has been too long...
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)