• Re: tic files

    From Vk3jed@432:1/101 to Rampage on Wed May 27 01:56:00 2020
    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)
  • From Nelgin@432:1/128 to Vk3jed on Tue May 26 16:22:32 2020
    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)
  • From Vk3jed@432:1/101 to Nelgin on Thu May 28 01:33:00 2020
    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)
  • From Rampage@432:1/139 to Vk3jed on Thu May 28 15:36:41 2020
    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)
  • From Vk3jed@432:1/101 to Rampage on Sat May 30 00:48:00 2020
    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)