Re: Re: tic files
By: Vk3jed to Rampage on Tue May 26 2020 20:56:00
it is but that's not how it should be doing... it should be replacing
the old copy of itself... no calculations needed...
Vk3jed> That can be arranged, though the filename changes each weeks.
right... that's how it is supposed to work...
why? because when it replaces the older one with the previous name,
when it is copied into the filebase, there's already one of the same
name in the way... the replaces line signaled to replace the previous
version but it can't replace this current version number from 100 days
ago... replaces should replace the current file...
Vk3jed> Well, all I was intending to do was replace the previous week's nodelist.
right but the problem is you have to replace two files since the system has been running and keeping the last 100... you cannot replace two files via TIC, though...
why last 100? because that's where the two digits in the archive extension loop
back to 00... you get 00 through 99 and back to 00... over time (several years) there will end up being 100 files in the area but they won't all be from
the same year because of the way the days of the week move each year... eg: jan 1 on monday, next year it is on tuesday, then wednesday, then friday because of feb 29 in leap year... there is a pattern, though...
i understand the reasoning but i'm not sure about it... on a clean system just starting to pull the area, replacing last weeks file with this weeks would result in only one file in the area... that kinda breaks an operator's possible
desire to keep archives in the area but yeah, there's the overlap to think about...
i'm not sure which way to go... you could keep the replacement of last weeks file and those of us with more than one would have to enable forced-replace for
the area or we've got to manually delete all the existing files except the one
for last week at which point your method would work just fine...
personally, i wish there was a better way of numbering the nodelist files... the best would be using the four digit year and the DoY in similar fashion that
satellite TLEs are numbered... i'm also not even sure why we're still archiving the nodelists in this day in time ;)
eg: vkr2020.123
if we could reliably use LFNs for TIC stuffs, it would be easy to do but alas we have so many in the paths that still cannot do better than 8.3 for numerous reasons...
)\/(ark
--- SBBSecho 3.11-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (432:1/139)