@MSGID: 2631.fidosoft@1:154/700 2e515b20
@REPLY: 48.husky@1:2320/107 2e50cc47
@TZUTC: -0500
@PID: Synchronet 3.22a-Linux master/9019e4bcb Apr 20
2026 GCC 15.2.1
@TID: SBBSecho 3.37-Linux master/9019e4bcb Apr 20
2026 GCC 15.2.1
@BBSID: PHARCYDE
@CHRS: UTF-8 4
@FORMAT: flowed
@NOTE: Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:140.0) Gecko/20100101Thunderbird/140.9.1
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)
SEEN-BY: 19/10 50/109 104/117 119 114/10 120/616
153/757 154/10 30 50 700
SEEN-BY: 218/840 220/20 90 221/1 6 360 226/18 20
44 50 280/464 301/1 335/364
SEEN-BY: 341/66 234 452/28 166 460/58 463/68
2320/105 3634/12 5000/111
SEEN-BY: 5010/352 5015/46 5020/715 828 846 848
1042 4441 12000 5030/49 1081
SEEN-BY: 5053/51 5061/133 5075/128 5083/444
@PATH: 154/700 10 221/6 5020/1042 4441