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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)