@MSGID: 1:154/700 69eead0c
@REPLY: 56.husky@1:2320/107 2e5212c8
@PID: GED+LNX 1.1.5-b20260425
@TID: SBBSecho 3.37-Linux master/685942705 Apr 26
2026 GCC 15.2.1
@BBSID: PHARCYDE
@TZUTC: -0500
@CHRS: UTF-8 4
@FORMAT: flowed
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)
SEEN-BY: 19/10 50/109 104/117 119 114/10 120/616
153/757 154/10 30 50 700
SEEN-BY: 218/840 220/20 90 221/1 6 360 226/18 20
44 50 280/464 301/1 335/364
SEEN-BY: 341/66 234 452/28 166 460/58 463/68
2320/105 3634/12 5000/111
SEEN-BY: 5010/352 5015/46 5020/715 828 846 848
1042 4441 12000 5030/49 1081
SEEN-BY: 5053/51 5061/133 5075/128 5083/444
@PATH: 154/700 10 221/6 5020/1042 4441