BBS:      TELESC.NET.BR
Assunto:  Re: htick "issue"
De:       Mike Powell
Data:     Fri, 24 Apr 2026 11:11:03 -0500
-----------------------------------------------------------

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

-----------------------------------------------------------
[Voltar]