On 05-25-20 21:32, Rampage wrote to Vk3jed <=-

it is but that's not how it should be doing... it should be replacing
the old copy of itself... no calculations needed...

That can be arranged, though the filename changes each weeks.

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

Well, all I was intending to do was replace the previous week's nodelist.

FWIW: wildcards used to work but it gave too much power over "my" file areas to
distributors...

Understandable!


... Adam to Eve-> 'I'll wear the plants in this family'.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (432:1/101)

Vk3jed wrote:

On 05-22-20 13:34, Nelgin wrote to everyone <=-

Working with 'VKRADIO.z43' in 'VK_NODE'.
Moving /sbbs/fido/inbsecure/VKRADIO.z43 to
/sbbs/data/dirs/vkradio/vkradio_vk_node/.
"VKRADIO.z43" already exists in
"/sbbs/data/dirs/vkradio/vkradio_vk_node/", but
TIC Replaces line is "VKRADIO.z36"
Abandoning /sbbs/fido/inbsecure/VKRADIO.tic

It looks like it's been a year coming around and now the nodelist isn't
able to
be updated. I can add a replaced line manually, but still - it should
probably
be in the tic file so we can continue to process.

Hmm, weird. The Replaces line should be calculated automatically each

week.

Actually, the script I use saves the filename used each week, so it can be

used

the following week in the Replaces line. I'll have to investigate. :/

OK, thanks.
--- SBBSecho 3.11-Linux
* Origin: End Of The Line BBS - endofthelinebbs.com (432:1/128)

On 05-26-20 11:22, Nelgin wrote to Vk3jed <=-

Actually, the script I use saves the filename used each week, so it can be

used

the following week in the Replaces line. I'll have to investigate. :/

OK, thanks.

No probs.


... Omens are there to be broken.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (432:1/101)

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)

On 05-28-20 10:36, Rampage wrote to Vk3jed <=-

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

Yeah, I can see your point. I've also noticed that not all systems can do a Replaces on a different filename, so I may just go with replacing the same name, which is a trivial change.

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 ;)

That would be a better system, if only it was practical.

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

Yes, I don't see us ever getting away from the 8.3 limitation for a long time, if ever.


... Dr. Livingston I. Presume (Dr. Presume's full name)
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (432:1/101)