@MSGID: 56.husky@1:2320/107 2e5212c8
@REPLY: 1:154/10 69ecb49f
@TZUTC: -0500
@PID: Synchronet 3.21a-Linux master/123f2d28a Jul 12
2025 GCC 12.2.0
@TID: SBBSecho 3.28-Linux master/123f2d28a Jul 12
2025 GCC 12.2.0
@BBSID: CAPCITY2
@CHRS: ASCII 1
@FORMAT: flowed
> 3 of the same file (2 renamed), with 3 .tic files. The latest .tic file that
> was being processed was not sent with the original (not renamed) file.

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.

> There are no bad blocks. The original file`s filesize changed, and the .tic
> that was being processed reflected that.

> Nothing crazy or fancy. The first (of three) files just wasn`t processed fast
> enough, before the second one showed up and ruined the party. ;)

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.

I forget what schedule tickit ran on (at least once a day), but htick runs
every 10 minutes! ;)

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.


 * SLMR 2.1a * PRESS To test.  RELEASE to detonate.
--- SBBSecho 3.28-Linux
 * Origin: Capitol City Online (1:2320/107)
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 106 107 304 3634/12
SEEN-BY: 5000/111 5010/352 5015/46 5020/715 828 846
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5053/51 5061/133 5075/128
5083/444 12320/7
@PATH: 2320/107 105 154/10 221/6 5020/1042 4441