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)