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?

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