@MSGID: 1:154/700 69eea9f3
@REPLY: 55.husky@1:2320/107 2e5212c7
@PID: GED+LNX 1.1.5-b20260425
@TID: SBBSecho 3.37-Linux master/685942705 Apr 26
2026 GCC 15.2.1
@BBSID: PHARCYDE
@TZUTC: -0500
@CHRS: UTF-8 4
@FORMAT: flowed
Hey Mike!

On Sat Apr 25 2026 , you wrote:

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

 If there isn`t an uppercase one to replace (in the actual fileecho,
not your inbound), it will do nothing. It won`t crash or stop anything
else from happening, or anything like that.

 The fact that you had multiple copies in your inbound directory,
means your processor wasn`t actually processing anything.

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

 No. It doesn`t cause an issue in that regard. You`re referring to
the inbound directory. The "REPLACES" tag works for the actual fileecho
the file gets processed to, not your inbound.

 Either way, if there is no file in that directory to replace, it
will continue to process the .tic and replace nothing.

 > 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 happens sometimes. You can safely delete them along with any tic
files related to them, and it should be fine.

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

 No need. Just make sure your processor runs when the file arrives
(even when that specific session is over, is fine). But don`t wait a
week or two to run htick to process, or you will probably have a few
other overwritten files.

 If you made the switch from tickit to htick, there may have been
a timeframe during that time you weren`t processing as they came in,
or even tickit was configured to process at intervals, rather than
immediately when the .tic is received. Either way, no need to be alarmed or
anything. It can happen, and it can get cleaned up and things go back to
normal operation.

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