BBS: TELESC.NET.BR Assunto: htick "issue" De: Nick Boel Data: Sun, 26 Apr 2026 19:12:51 -0500 ----------------------------------------------------------- Hey Mike! On Sat Apr 25 2026 , you wrote: > No, it was actually three of the same named file (x2 as it comes with a > companion - total 6) and only one tic file (x2, one for each - total 2). > The tics were received with the latest installment. I'm not arguing symantics. What I said still holds true. > The first of three sets landed in September when I was still using > tickit. The second in March, after I had switched to htick, and the > third this month. I check that log once a day so it didn't start > throwing any errors into the log until the third set was recently received. So you haven't cleared bad packets, or bad/old tics from your inbound since at least September? This is probably not a binkd or tic processor issue, at this point. > I forget what schedule tickit ran on (at least once a day), but htick > runs every 10 minutes! ;) Running your tic processor once a day (or even every 10 minutes) is exactly why this happened. It doesn't happen very often, but it happens nonetheless. htick (or even tickit) should run as soon as a tic file is received, if you want to avoid this in the future. Basically, and specifically with this exact scenario; if Nick were to hatch a D'Bridge release, then realize he made a typo and re-hatch it 5 minutes later, both of your methods of processing above would fail, as you would have one "db4s.zip", and when the second one comes in, it would be "db4s.zip.1", with two .tic files in your inbound. If the wrong tic file gets processed, it will cause a CRC/filesize error and will fail. Not sure what mailer you're using, but with binkd I use this in the config: exec "/home/user/fido/scripts/htick.sh" *.[Tt][Ii][Cc] If you're using binkit or whatever it's called, you might want to look into how to invoke the tic processor upon receipt of a tic file, or you will probably eventually run into this issue again in the future. > I very much suspect the issue triggered because the REPLACES doesn't > match, which is causing files of the same name (with a digit added on > the end) to pile up and eventually this causes an issue. Again, as I said before, the REPLACES command does not affect what is in your INBOUND directory. It is for the fileecho. If you store db4s.zip in a directory called "/home/user/files/dbridge" once the file is processed - THAT is where it will replace the file. Regards, Nick ... Sarcasm: because beating people up is illegal. --- SBBSecho 3.37-Linux * Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700) ----------------------------------------------------------- [Voltar]