Hello All,

Whoever is releasing STINGER.ZIP is releasing it twice in a very short period of time on the same day every week. Can you please cut that down to only once? Or, if you absolutely must hatch it out twice, space it out timewise a bit?

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20130910
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/701)

Hi Nick,

Whoever is releasing STINGER.ZIP is releasing it twice in a very short period
of time on the same day every week. Can you please cut that down to only once?
Or, if you absolutely must hatch it out twice, space it out timewise a bit?

That would be Ben Ritchey. He sends out updates for that file.

Take care,
Janis

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)

Hi Nick,

Whoever is releasing STINGER.ZIP is releasing it twice in a very short period
of time on the same day every week. Can you please cut that down to only once?
Or, if you absolutely must hatch it out twice, space it out timewise a bit?

You can see each of the releases are different file sizes:

140917 02:00 BTICK: Processing file STINGER.ZIP in AVWINXP (22844kB).
140917 10:51 BTICK: Processing file STINGER.ZIP in AVWINXP (21772kB).
140917 10:52 BTICK: Processing file STINGER.ZIP in AVWINXP (22842kB).

140924 01:30 BTICK: Processing file STINGER.ZIP in AVWINXP (22874kB).
140924 01:52 BTICK: Processing file STINGER.ZIP in AVWINXP (22877kB).

141001 02:30 BTICK: Processing file STINGER.ZIP in AVWINXP (22906kB).
141001 02:55 BTICK: Processing file STINGER.ZIP in AVWINXP (22905kB).

Given the updates in virus "stuff" it makes some sense... but let's see what Ben has to say. I'm just guessing here <g>

Take care,
Janis

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)

Hello Janis,

On 01 Oct 14 22:19, Janis Kracht wrote to Nicholas Boel:

Hi Nick,

Whoever is releasing STINGER.ZIP is releasing it twice in a very
short period of time on the same day every week. Can you please cut
that down to only once? Or, if you absolutely must hatch it out
twice, space it out timewise a bit?

You can see each of the releases are different file sizes:

Should they then be named differently as to not overwrite each other? Either way, I end up with one STINGER.ZIP and one STINGER.ZIP.1 (because one already exists) and two TIC files, and the errors are a CRC mismatch so they don't process correctly..

140917 02:00 BTICK: Processing file STINGER.ZIP in AVWINXP (22844kB). 140917 10:51 BTICK: Processing file STINGER.ZIP in AVWINXP (21772kB). 140917 10:52 BTICK: Processing file STINGER.ZIP in AVWINXP (22842kB).

140924 01:30 BTICK: Processing file STINGER.ZIP in AVWINXP (22874kB). 140924 01:52 BTICK: Processing file STINGER.ZIP in AVWINXP (22877kB).

141001 02:30 BTICK: Processing file STINGER.ZIP in AVWINXP (22906kB). 141001 02:55 BTICK: Processing file STINGER.ZIP in AVWINXP (22905kB).

Somehow yours processed 25 minutes apart, yet both were received here in the same transmission with Ross and processed at the same time. That doesn't work out too well, unless I specifically specify binkd to launch my file processor after every single TIC arrival, while forcing it to do it during the current session, rather than waiting until the session ends to run the file processor.

Given the updates in virus "stuff" it makes some sense... but let's
see what Ben has to say. I'm just guessing here <g>

The updates in virus "stuff" is fine and all, but why two mismatched files with
the same filename in such a short period? If there's virus definitions to update, then release one STINGER.ZIP every day with the "replace" option..

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20130910
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/701)

Hey Nick,

Should they then be named differently as to not overwrite each other? Either

No. From what I can gather they are the the current updates of the stinger w32/w64 files to remove virii from files. Given all the crap we deal with virus-wise, it makes sense <grin>

way, I end up with one STINGER.ZIP and one STINGER.ZIP.1 (because one already exists) and two TIC files, and the errors are a CRC mismatch so they don't process correctly..

Ok.. as soon as they come in, they go out to your uplink (I guess Ross).

If Ben isn't hatching with replace, that's a mistake, but I think he is.. I'll check my logs tomorrow.

The problem I'm seeing with your description is you aren't getting them as they
are released.. more like either Ross is timing when he sends to you or you are timing when you pick up. Maybe ask him to send crash as soon as the files come
in, and then you'd have to process as soon as anything came in.. that's what I do.

140917 02:00 BTICK: Processing file STINGER.ZIP in AVWINXP (22844kB).
140917 10:51 BTICK: Processing file STINGER.ZIP in AVWINXP (21772kB).
140917 10:52 BTICK: Processing file STINGER.ZIP in AVWINXP (22842kB).

140924 01:30 BTICK: Processing file STINGER.ZIP in AVWINXP (22874kB).
140924 01:52 BTICK: Processing file STINGER.ZIP in AVWINXP (22877kB).

141001 02:30 BTICK: Processing file STINGER.ZIP in AVWINXP (22906kB).
141001 02:55 BTICK: Processing file STINGER.ZIP in AVWINXP (22905kB).

Somehow yours processed 25 minutes apart, yet both were received here in the same transmission with Ross and processed at the same time. That doesn't work

Yep...

out too well, unless I specifically specify binkd to launch my file processor after every single TIC arrival, while forcing it to do it during the current
session, rather than waiting until the session ends to run the file processor.

Hmm... my file processor and mail tosser runs as soon as it see anything in the
inbound..

Given the updates in virus "stuff" it makes some sense... but let's
see what Ben has to say. I'm just guessing here <g>

The updates in virus "stuff" is fine and all, but why two mismatched files wit
the same filename in such a short period? If there's virus definitions to update, then release one STINGER.ZIP every day with the "replace" option..

From what I can see, sometimes STINGER gets updated more than once a day.. at least right now.

I could be wrong but I think the problem isn't the filename or the number of times it is hatched..the problem would seem to be with your connection with Ross.

Take care,
Janis

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)

* An ongoing debate between Nicholas Boel and All rages on ...

Whoever is releasing STINGER.ZIP is releasing it twice in a very short period of time on the same day every week. Can you please cut that
down to only once? Or, if you absolutely must hatch it out twice,

I will research the hatching but it's only set to hatch out once early in the Am when the VM machine boots up. If for some reason the VM is re-started, it will re-hatch, so I will look into fixing that, sorry.

--
Guardien Fide :^)

Ben aka cMech Web: http://cmech.dynip.com
Email: fido4cmech(at)lusfiber.net
Home page: http://users.lusfiber.net/~fido4cmech
WildCat! Board 24/7 +1-337-984-4794 any BAUD 8,N,1

--- GoldED+/W32-MSVC
* Origin: FIDONet - The Positronium Repository (1:393/68)

On Wed, 01 Oct 2014, Janis Kracht wrote to Nicholas Boel:

Whoever is releasing STINGER.ZIP is releasing it twice in a very
short period of time on the same day every week. Can you please cut
that down to only once? Or, if you absolutely must hatch it out
twice, space it out timewise a bit?

You can see each of the releases are different file sizes:

the problem i see is of similar nature to the nodelist files of the same name in different areas... the second file to arrive overwrites the original not-yet-processed one but both tics remain... allfix sees the file doesn't match the first tic so it sidelines them... when it gets to the second tic, the
file doesn't exist so it sidelines the second tic too... this happens endlessly
at each processing even when -tossbad is used... it requires manual intervention to figure out which tic goes with the remaining file and deleting the other(s) that may point to the same filename...

stinger isn't the newest one with this problem... we had the nodelist thing a while back... i also see this all the time in the three or four ECHOxxxx files from the R50 area... there are others but i cleaned stuff up the other day and they haven't hit again and i don't remember them...

i process mail once an hour... i can only imagine the troubles that a systems that processes only once or twice a day would see... deity knows what kinda mess one sees when they return from some days of down time and pull multiple hatchings of the same filename...

yeah, extension renumbering? that'll help keep the subsequent files but still requires manual intervention... that's something i need to figure out how to do
in my hybrid processing setup, too... right now when the files are moved to the
central processing area, they will overwrite others of the same name that exist
in there... that script is already ugly as sin and will get uglier as time goes
on...

)\/(ark


* Origin: (1:3634/12)

Hello Ben,

On 02 Oct 14 00:44, Ben Ritchey wrote to Nicholas Boel:

Whoever is releasing STINGER.ZIP is releasing it twice in a very
short period of time on the same day every week. Can you please
cut that down to only once? Or, if you absolutely must hatch it
out twice,

I will research the hatching but it's only set to hatch out once early
in the Am when the VM machine boots up. If for some reason the VM is re-started, it will re-hatch, so I will look into fixing that, sorry.

Thanks for taking a look, Ben. :)

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20130910
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/701)

* An ongoing debate between Nicholas Boel and Ben Ritchey rages on ...

Whoever is releasing STINGER.ZIP is releasing it twice in a very
short period of time on the same day every week. Can you please
cut that down to only once? Or, if you absolutely must hatch it
out twice,

I will research the hatching but it's only set to hatch out once
early in the Am when the VM machine boots up. If for some reason
the VM is re-started, it will re-hatch, so I will look into
fixing that, sorry.

Thanks for taking a look, Ben. :)

NP I fixed the re-hatch glitch on the VM re-boots and will watch for anything else. :)

--
Guardien Fide :^)

Ben aka cMech Web: http://cmech.dynip.com
Email: fido4cmech(at)lusfiber.net
Home page: http://users.lusfiber.net/~fido4cmech
WildCat! Board 24/7 +1-337-984-4794 any BAUD 8,N,1

--- GoldED+/W32-MSVC
* Origin: FIDONet - The Positronium Repository (1:393/68)

Hello Ben,

On 02 Oct 14 17:55, Ben Ritchey wrote to Nicholas Boel:

NP I fixed the re-hatch glitch on the VM re-boots and will watch for anything else. :)

Thank you. You rock, mang! :)

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20130910
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/701)