BBS:      TELESC.NET.BR
Assunto:  htick "issue"
De:       Mike Powell
Data:     Mon, 27 Apr 2026 10:08:54 -0500
-----------------------------------------------------------
> Running your tic processor once a day (or even every 10 minutes) is exactly wh
> 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.

No it is not exactly why.  Dates that a month or more apart are > 10 minutes
apart.

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

If the issue isn't logged (which is wasn't until this time) how would I
know to clear them from the inbound?  Now that I am running htick and errors
actually show up, I have.

My initial question was "is there a way to tell htick to go ahead and
process the files" when it gets an error that, to me, isn't important.

The answer is "no" so the question is answered.

The issue with not logging... or why the earlier TIC files were deleted while
the files were left unprocessed... is probably a tickit issue so I think it is
off topic here.  tickit doesn't run here any more so it is also irrelevant.

I still maintain that the REPLACES not matching the case of the files
received is eventually going to cause a problem... whether it just be
duplicate files or something else remains to be seen.  I will worry about
it when it happens again.  I don't think that htick is the cause of that,
either, as I doubt it changes file cases on its own, so it is probably also
off topic here.


 * SLMR 2.1a * Strip mining prevents forest fires.
--- SBBSecho 3.28-Linux
 * Origin: Capitol City Online (1:2320/107)

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