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.
Is there a way to get htick to ignore these issues and go ahead and process the files?
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.
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.
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.
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.
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.
After further examination, all tics involved in this issue originate
from 1:154/10 (see below).
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.
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.
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,
It could be a real CRC/badblock problem on your or the sender system.
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.
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.
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.
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. ;)
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 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.
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.
I got it processed "by hand." ;) If that echo continues causing
issues, I will just drop it.
No, it was actually three of the same named file (x2 as it comes with a companion - total 6) and only one tic file (x2, one for each - total 2).
The tics were received with the latest installment.
The first of three sets landed in September when I was still using
tickit. The second in March, after I had switched to htick, and the
third this month. I check that log once a day so it didn't start
throwing any errors into the log until the third set was recently received.
I forget what schedule tickit ran on (at least once a day), but htick
runs every 10 minutes! ;)
I very much suspect the issue triggered because the REPLACES doesn't
match, which is causing files of the same name (with a digit added on
the end) to pile up and eventually this causes an issue.
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.
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.
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.
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.
If you know that your uplink will always send you lowercase files, once those are in the directory they're supposed to be in, you can safely remove the uppercase or mixed case ones (ie. manual cleanup, as I don't think any tic processor does that for you). If you were to ever switch hubs, you may have to do it all over again, depending on how they treat their own incoming files.
I agree with you on the last bit, though.. htick was definitely not the original cause. However, it was in fact what told you there was an issue! ;)
If you currently have no issues with htick, and no unprocessed .tic files in your secure inbound directory, then I would suggest you start clean slate now and keep an eye on your logs. If anything new comes about, I'll gladly try to help you get it squared away!
| Sysop: | Angel Ripoll |
|---|---|
| Location: | Madrid, Spain |
| Users: | 20 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 25:42:17 |
| Calls: | 1,187 |
| Files: | 1,924 |
| Messages: | 67,540 |