BBS: TELESC.NET.BR Assunto: Re: htick "issue" De: Nick Boel Data: Fri, 24 Apr 2026 20:37:29 -0500 ----------------------------------------------------------- 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) ----------------------------------------------------------- [Voltar]