• DailyList ...

    From Rj Clay@1:120/546 to Janis Kracht on Wednesday, October 09, 2013 13:01:36
    Janis,

    Was wondering why todays DailyList nodelist was twice as large as yesterdays'; it seems it has two nodelists in it... (182 & 282)



    Jame


    --- BBBS/Li6 v4.10 Dada-1
    * Origin: BBBS Info at Rocasa (1:120/546)
  • From Janis Kracht@1:261/38 to Rj Clay on Thursday, October 10, 2013 09:29:48
    Hi Jame,

    Was wondering why todays DailyList nodelist was twice as large as yesterdays'; it seems it has two nodelists in it... (182 & 282)

    Hmm.. Time to clean out that directory of old nodelists I guess, but I wouldn't
    think it necessary... I will investigate though. Thanks Jame.

    Take care,
    Janis

    --- BBBS/Li6 v4.10 Dada-1
    * Origin: Prism bbs (1:261/38)
  • From Benny Pedersen@2:230/0 to Janis Kracht on Friday, October 11, 2013 21:32:38
    Hello Janis!

    10 Oct 2013 09:29, Janis Kracht wrote to Rj Clay:

    Was wondering why todays DailyList nodelist was twice as large as
    yesterdays'; it seems it has two nodelists in it... (182 & 282)

    Hmm.. Time to clean out that directory of old nodelists I guess, but I wouldn't think it necessary... I will investigate though. Thanks
    Jame.

    tmpwatch can do it from cron ?

    here i just keep last 90 days of nodelists, older is not usefull anymore


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.2.0 (Linux/3.11.4-gentoo (i686))
    * Origin: duggi.junc.org where qico is waiting (2:230/0)
  • From mark lewis@1:3634/12 to Benny Pedersen on Friday, October 11, 2013 21:09:51

    On Fri, 11 Oct 2013, Benny Pedersen wrote to Janis Kracht:

    here i just keep last 90 days of nodelists, older is not usefull
    anymore

    not even for historical purposes? it is too late now, though...

    )\/(ark


    * Origin: (1:3634/12)
  • From Janis Kracht@1:261/38 to Benny Pedersen on Friday, October 11, 2013 18:55:50
    Hi Benny,

    Was wondering why todays DailyList nodelist was twice as large as
    yesterdays'; it seems it has two nodelists in it... (182 & 282)

    Hmm.. Time to clean out that directory of old nodelists I guess, but I
    wouldn't think it necessary... I will investigate though. Thanks
    Jame.

    tmpwatch can do it from cron ?

    here i just keep last 90 days of nodelists, older is not usefull anymore

    Makenl should just clean up after itself.. that would make the most sense for a
    zone coordinator creating full nodelists, which is a bit different than what you are talking about.

    Take care,
    Janis

    --- BBBS/Li6 v4.10 Dada-1
    * Origin: Prism bbs (1:261/38)
  • From Andrew Leary@1:320/219 to Janis Kracht on Saturday, October 12, 2013 03:28:48

    Hello Janis!

    11 Oct 13 18:55, you wrote to Benny Pedersen:

    Makenl should just clean up after itself.. that would make the most
    sense for a zone coordinator creating full nodelists, which is a bit different than what you are talking about.

    Add "Cleanup 1" to your .CTL file and it will delete old output files after it completes processing.

    Andrew


    --- GoldED+/LNX 1.1.5-b20130111
    * Origin: Phoenix BBS * bnbbbs.dyndns.org:2323 (1:320/219)
  • From mark lewis@1:3634/12 to Andrew Leary on Saturday, October 12, 2013 12:34:27

    On Sat, 12 Oct 2013, Andrew Leary wrote to Janis Kracht:

    Makenl should just clean up after itself.. that would make the
    most sense for a zone coordinator creating full nodelists, which
    is a bit different than what you are talking about.

    Add "Cleanup 1" to your .CTL file and it will delete old output
    files after it completes processing.

    how old? all old ones?

    )\/(ark


    * Origin: (1:3634/12)
  • From Andrew Leary@1:320/119 to mark lewis on Saturday, October 12, 2013 13:21:47
    Hello mark!

    Saturday October 12 2013 12:34, mark lewis wrote to Andrew Leary:

    Add "Cleanup 1" to your .CTL file and it will delete old output
    files after it completes processing.

    how old? all old ones?

    It should be everything older than 7 weeks. I will test that and confirm tonight.

    Andrew

    ---
    * Origin: Bits & Bytes BBS * V.Everything! * 860/535-4284 (1:320/119)
  • From Benny Pedersen@2:230/0 to mark lewis on Saturday, October 12, 2013 22:54:54
    Hello mark!

    11 Oct 2013 21:09, mark lewis wrote to Benny Pedersen:

    here i just keep last 90 days of nodelists, older is not usefull
    anymore

    not even for historical purposes? it is too late now, though...

    i have lost my mind aswell


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.2.0 (Linux/3.11.4-gentoo (i686))
    * Origin: duggi.junc.org where qico is waiting (2:230/0)
  • From Benny Pedersen@2:230/0 to Janis Kracht on Saturday, October 12, 2013 22:55:50
    Hello Janis!

    11 Oct 2013 18:55, Janis Kracht wrote to Benny Pedersen:

    Makenl should just clean up after itself.. that would make the most
    sense for a zone coordinator creating full nodelists, which is a bit different than what you are talking about.

    +1, agre on that, but the main problem is that tic files have limted replace line support :)

    and if one have archive bbs, it might be complete ignored


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.2.0 (Linux/3.11.4-gentoo (i686))
    * Origin: duggi.junc.org where qico is waiting (2:230/0)
  • From mark lewis@1:3634/12 to Benny Pedersen on Saturday, October 12, 2013 20:27:14

    On Sat, 12 Oct 2013, Benny Pedersen wrote to Janis Kracht:

    Hello Janis!

    11 Oct 2013 18:55, Janis Kracht wrote to Benny Pedersen:

    Makenl should just clean up after itself.. that would make the
    most sense for a zone coordinator creating full nodelists, which
    is a bit different than what you are talking about.

    +1, agre on that, but the main problem is that tic files have
    limted replace line support :)

    but that has nothing to do with the app being able to work with a directory full of older output files... they are not very likely to reside in a bbs' file
    area, either ;)

    i am, however, curious about you statement... what do you meain by "limited replace line support"??

    and if one have archive bbs, it might be complete ignored

    very true! ;) i once lost years of files that had been distributed... most of those were lost due to aging off which was handled quite quickly... others, as you note, were replaced... either by newer versions with a different name or by
    others with the same name... different named ones are easy enough to deal with but same named ones present a different problem to deal with :?

    )\/(ark


    * Origin: (1:3634/12)
  • From Janis Kracht@1:261/38 to Benny Pedersen on Saturday, October 12, 2013 23:41:24
    Hi Benny,

    Makenl should just clean up after itself.. that would make the most
    sense for a zone coordinator creating full nodelists, which is a bit
    different than what you are talking about.

    +1, agre on that, but the main problem is that tic files have limted replace line support :)

    Replace wouldn't be an issue with nodelists, because the extension is always different.. say different from a file like "DAILYWET.ZIP" (daily weather map).

    Unless I'm not understanding you here..

    and if one have archive bbs, it might be complete ignored

    Still not sure what you mean here :(

    Take care,
    Janis

    --- BBBS/Li6 v4.10 Dada-1
    * Origin: Prism bbs (1:261/38)
  • From Janis Kracht@1:261/38 to mark lewis on Saturday, October 12, 2013 23:45:44
    Hi Mark,

    i am, however, curious about you statement... what do you meain by "limited replace line support"??

    Yes, same here <g>

    and if one have archive bbs, it might be complete ignored

    very true! ;) i once lost years of files that had been distributed... most of >those were lost due to aging off which was handled quite quickly... others, as >you note, were replaced... either by newer versions with a different name or b >others with the same name... different named ones are easy enough to deal with
    but same named ones present a different problem to deal with :?

    I think the only files I've "lost" were due to my own sillyness.. like fat-fingering "rm * ~" Lol.. yes, that was nasty.. I have a safe del too, that I never use haha.. anyway, I can't think of a time when a tick caused any files
    I didn't want cleaned up to be deleted..

    Take care,
    Janis

    --- BBBS/Li6 v4.10 Dada-1
    * Origin: Prism bbs (1:261/38)
  • From mark lewis@1:3634/12 to Janis Kracht on Sunday, October 13, 2013 13:38:26

    On Sat, 12 Oct 2013, Janis Kracht wrote to mark lewis:

    i am, however, curious about you statement... what do you meain by "limited >
    replace line support"??

    Yes, same here <g>

    maybe we'll see an answer soonish ;)

    and if one have archive bbs, it might be complete ignored

    very true! ;) i once lost years of files that had been
    distributed... most of those were lost due to aging off which was
    handled quite quickly... others, as you note, were replaced... either
    by newer versions with a different name or by others with the same
    name... different named ones are easy enough to deal with
    but same named ones present a different problem to deal with :?

    I think the only files I've "lost" were due to my own sillyness..

    yeah, i've done that too... in my case, i had originally set up so that files were retained for at least a year... maybe two or three... when i finally realized that the FDN wasn't distributing files any more, it was too late and i
    had to go hunt down whatever i could find... that was the fernwood stuff... at that time i reconfigured for no aging off of files and i'm not sure, at the moment, about the REPLACE verb being honored... i have to look to see but a better option would be for REPLACE to trigger a move of the file being replaced
    to an archivial directory...

    like fat-fingering "rm * ~" Lol.. yes, that was nasty..

    i can imagine!

    I have a safe del too, that I never use haha..

    alias it to rm ;)

    anyway, I can't think of a time when a tick caused any files I
    didn't want cleaned up to be deleted..

    me either...

    )\/(ark


    * Origin: (1:3634/12)
  • From Gert Andersen@2:230/150 to Janis Kracht on Thursday, October 17, 2013 15:50:46
    Hello Janis!

    Sat Oct 12 2013, Janis Kracht wrote to mark lewis:

    i am, however, curious about you statement... what do you meain by
    "limited replace line support"??

    Yes, same here <g>

    and if one have archive bbs, it might be complete ignored

    very true! ;) i once lost years of files that had been distributed...
    most of those were lost due to aging off which was handled quite
    quickly... others, as you note, were replaced... either by newer versions
    with a different name or b others with the same name... different named
    ones are easy enough to deal with but same named ones present a different
    problem to deal with :?

    I think the only files I've "lost" were due to my own sillyness.. like
    fat-fingering "rm * ~" Lol.. yes, that was nasty.. I have a safe del
    too, that I never use haha.. anyway, I can't think of a time when a
    tick caused any files I didn't want cleaned up to be deleted..


    A idea could be a script file to use before makenl is running there is checking
    for a old nodelist exist and if there is a old nodelist.282 then move it to another directory if you like to have it for some checking of nodes.
    When I making my nodelist for other networks is there olny a nodelist from last
    run of makenl, but in my file areas for nodediff and nodelist can be older files.
    For some years back were I getting zone2 made nodelist and nodediff in uppercase and now is i getting them in lowercase so the old ones in uppercase not have been moved out.

    Take care,
    Gert

    - Get the best with linux -

    --- Msged/LNX 6.2.0 (Linux/2.6.39-gentoo-r1 (x86_64))
    * Origin: KofoBBS at ftp://fido1.kofobbs.net (2:230/150)