@MSGID: 48.husky@1:2320/107 2e50cc47
@REPLY: 2624.fidosoft@1:154/700 2e4fdddb
@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

 > In the last line, it says "in tic: ef043450". This doesn`t seem to match the
 > original tic that came from my system (0urbuzff.tic), which is most likely
 > why there was a CRC issue.

 > Are you getting this file and/or fileecho from multiple hubs? It seems you
 > have 3 of the same file that overwrote each other, and it looks like you (or
 > htick) deleted all three of them at some point?

After further examination, all tics involved in this issue originate from
1:154/10 (see below).

 > Almost seems like before the original .tic was processed, you got another
 > tic and the same db4s.zip from another system, and then possibly even
 > another one after that.

That is happening because the replaces doesn`t match the file name case and the
files are always named the same - no version number - so there are three
versions with three different dates.

 > If you still have a file named "db4s.zip", that may not be the one that came
 > with the .tic file that is being processed. If you do have multiple file
 > hubs for the same fileechos, I`d recommend not doing that. While it works
 > with echomail (because of dupe checking), I`m not so sure it works very well
 > with files.

Here is the issue, as best as I can tell:

Created by HTick, written by Gabriel Plutzar
File db4s.zip
Area DBRIDGE
Areadesc DB: D`Bridge Software Releases
Desc D`Bridge 4 Standard Edition
LDesc D`Bridge 4 Standard Edition
Replaces DB4S.ZIP
From 1:154/10

The "File" value, and the dataset name received, are in lower case.
The `Replaces` is in upper.

Because the files are always named the same and, at least the last three times,
have landed here with lower case names, they are not getting replaced.  I am
guessing that htick has started having difficulty telling which is which.

Not sure why the first one didn`t get processed.  Based on the datestamp, it
landed here before I replaced synchronet`s tic processing -- which seemed
unreliable -- with htick.

I am guessing tickit failed to process it, left it in the inbound, and
eventually a new same-named file landed.  Since the Replaces don`t match, the
errors started.

Now, if the case in the dataset name of the `Replaces` isn`t relevant, then who
knows why htick isn`t just replacing it. ;)  I would guess it is a true
filesise/CRC error.

Mike
--- 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