Is there a way to get htick to ignore these issues and go ahead and process
the files?

7 00:20:01 Processing Tic-File /home/bbs/fido/inbound/0urbuzff.tic
7 00:20:01 File "db4s.zip": size: 2751653, area: DBRIDGE, from: 1:154/10, orig:
7 00:20:01 Size of file '/home/bbs/fido/inbound/db4s.zip' differs with TIC. I t
A 00:20:01 Can't check size of file "db4s.zip": No such file or directory. Skip
A 00:20:01 Can't check size of file "db4s.zip.1": No such file or directory. Sk
A 00:20:01 Can't check size of file "db4s.zip.2": No such file or directory. Sk
7 00:20:01 Wrong CRC for file "db4s.zip", skipping this file (in tic:ef043450,


I tried adding the '-b' parameter but that does not address issues such as these.

Mike


* SLMR 2.1a * I don't NEED Robocomm! ... I'm up at 4:00 am
--- SBBSecho 3.28-Linux
* Origin: Capitol City Online (1:2320/107)

Hey Mike!

On Thu, Apr 23 2026 10:10:49 -0500, you wrote:

Is there a way to get htick to ignore these issues and go ahead and
process the files?

7 00:20:01 Processing Tic-File /home/bbs/fido/inbound/0urbuzff.tic
7 00:20:01 File "db4s.zip": size: 2751653, area: DBRIDGE, from:
1:154/10, orig: 7 00:20:01 Size of file '/home/bbs/fido/inbound/
db4s.zip' differs with TIC. I t A 00:20:01 Can't check size of file "db4s.zip": No such file or directory. Skip A 00:20:01 Can't check
size of file "db4s.zip.1": No such file or directory. Sk A 00:20:01
Can't check size of file "db4s.zip.2": No such file or directory. Sk
7 00:20:01 Wrong CRC for file "db4s.zip", skipping this file (in tic:ef043450,

I tried adding the '-b' parameter but that does not address issues> such as these.

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?

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.

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.

Regards,
Nick

... Sarcasm, because beating people up is illegal.
--- SBBSecho 3.37-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)

Hello Mike!

23 Apr 26, Mike Powell wrote to ALL:

Is there a way to get htick to ignore these issues and go ahead and process the files?

? Doesn't htick do that already?

7 00:20:01 Size of file '/home/bbs/fido/inbound/db4s.zip' differs
Wrong CRC for file "db4s.zip", skipping this file (in tic:ef043450,

CRC means the file does not match the TIC. This is a serious issue and htick does ignore it by skipping.

That way the sysop can identify the reason for the issue and solve it.

My workaround for known files is a rename from "file" to "file-timestamp".

According to the file extensions .1 and .2 you have three versions of that file. This .1 .2 renaming is done by the mailer. If the original "file" is renamed at least the next tic with "file" will match.

That way the sysop can decide what to do with "file-timestamp" later.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

CRC means the file does not match the TIC. This is a serious issue and htick does ignore it by skipping.

That way the sysop can identify the reason for the issue and solve it.

I didn't hatch it so I wouldn't know what the issue is.

My workaround for known files is a rename from "file" to "file-timestamp".

According to the file extensions .1 and .2 you have three versions of that file. This .1 .2 renaming is done by the mailer. If the original "file" is renamed at least the next tic with "file" will match.

That way the sysop can decide what to do with "file-timestamp" later.

Sounds like the best workaround is to delete them so they stop polluting my logs.


* SLMR 2.1a * IBM = Institute of Black Magic
--- SBBSecho 3.28-Linux
* Origin: Capitol City Online (1:2320/107)

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.

To the best of my knowledge, I do not have multiple feeds for file echoes
but will check.

Since the CRC/file sizes don't seem to match on any of them, and there is apparently no way to force htick to process them, I am going to
delete them.


* SLMR 2.1a * Taglines: the toilet-stall walls of BBSdom.
--- SBBSecho 3.28-Linux
* Origin: Capitol City Online (1:2320/107)

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)

On 2026 Apr 24 10:50:44, you wrote to NICK BOEL:

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.

To the best of my knowledge, I do not have multiple feeds for file echoes but will check.

check the PATH in those tics and you'll likely find the multiple paths fairly easily... i have seen the same here with the FIDONEWS FDN since maybe 2019 or 2020...

)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... Cats teach us how to land on our feet
---
* Origin: (1:3634/12.73)

Hey Mike!

On Fri, Apr 24 2026 10:50:45 -0500, you wrote:

To the best of my knowledge, I do not have multiple feeds for file
echoes but will check.

Ok. Somehow you ended up with multiple copies.

Since the CRC/file sizes don't seem to match on any of them, and
there is apparently no way to force htick to process them, I am
going to delete them.

Good idea. Once you clear them, if you want a new copy of the file, and if I remember right, you can send a netmail to my filefix with:

%resend db4s.zip DBRIDGE

Or something like that.

Regards,
Nick

... Sarcasm, because beating people up is illegal.
--- SBBSecho 3.37-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)

Hey Mike!

On Fri, Apr 24 2026 11:11:03 -0500, you wrote:

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

Then I'm guessing multiple files were sent to me in a short(er) period.

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.

Correct. I was changing incoming files to lowercase with binkd, for years without issue. See below.

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.

Yessir, and understood. Uppercase filenames are stupid these days. 'Nuff said. ;)

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.

Typically, the first "db4s.zip" that would arrive on your system would use the REPLACES tag and replace your upper case one. From then on out, it would overwrite the latest lowercase one. This shouldn't be an issue if the first one was processed before the others arrived.

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.

It was probably just set to run at certain intervals, rather than immediately when the .tic is received. There have been a few D'Bridge releases recently. That's all I can think of.

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.

I don't think the REPLACES tag causes errors. It would just look for a DB4S.ZIP and replace it, if it's not there, it would process it and your directory would then maybe include two files, one uppercase and the other lowercase.

Granted, I can't say how tickit works, so maybe it's different.

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.

What I saw in your log was that it wasn't using the proper .tic file for the "db4s.zip" that was in your inbound. For example, the original db4s.zip was still there, the next two that arrived were renamed. The latest .tic file (the one that came with the file that was renamed to "db4s.zip.2" to arrive was being used on the old file, so that's where the CRC/filesize errors were occurring.

It's all good. As I mentioned in the previous message, delete all of them and the .tic files, grab it again with the filefix command I gave you. We'll see what happens next release.

Regards,
Nick

... Sarcasm, because beating people up is illegal.
--- SBBSecho 3.37-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)

Hello Mike!

24 Apr 26, Mike Powell wrote to NICK BOEL:

To the best of my knowledge, I do not have multiple feeds for file
echoes but will check.

Are the files being transfered without interruption? Wasn't there a mailer config option how to handle incompleted transfers?

Since the CRC/file sizes don't seem to match on any of them,

It could be a real CRC/badblock problem on your or the sender system.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Hey Kai!

On Sat, 25 Apr 2026 12:27:08 , you wrote:

It could be a real CRC/badblock problem on your or the sender system.

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.

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

Regards,
Nick

... Sarcasm: because beating people up is illegal.
--- GoldED+/LNX 1.1.5-b20260304
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

Typically, the first "db4s.zip" that would arrive on your system would use the
REPLACES tag and replace your upper case one. From then on out, it would overwrite the latest lowercase one. This shouldn't be an issue if the first on
was processed before the others arrived.

But then when the next db4s.zip arrives, there is no uppercase one to
replace. It looks to me like it won't replace the lowercase
dataset name, leaving the old (lowercase) one out there to cause a mismatch later.

I don't think the REPLACES tag causes errors. It would just look for a DB4S.ZI
and replace it, if it's not there, it would process it and your directory woul
then maybe include two files, one uppercase and the other lowercase.

I think it might cause an issue when the file already exists and it cannot replace it because the filename doesn't match. It then eventually tries to match a new tic with the older dataset, which is what happened here.

What I saw in your log was that it wasn't using the proper .tic file for the "db4s.zip" that was in your inbound. For example, the original db4s.zip was still there, the next two that arrived were renamed. The latest .tic file (the
one that came with the file that was renamed to "db4s.zip.2" to arrive was being used on the old file, so that's where the CRC/filesize errors were occurring.

That would make sense, since it was trying to match to "db4s.zip" and the
one it was finding was the old one from September.

It's all good. As I mentioned in the previous message, delete all of them and the .tic files, grab it again with the filefix command I gave you. We'll see what happens next release.

I got it processed "by hand." ;) If that echo continues causing issues, I will just drop it.


* SLMR 2.1a * Mason-Dixon Line n. Separates y'all from youse guys
--- SBBSecho 3.28-Linux
* Origin: Capitol City Online (1:2320/107)