I am trying to get a grasp of something I noticed about fsxNet, which gets snarfed into my file base and overwrites the previous nodelist, such that there is only ever one version of the nodelist present.

This seems ideal.

Most of my other networks I carry do not do this on my system. The new nodelists do not overwrite or supercede the others. Weekly nodelists pile up and I notice that mutil has a look at them all. Comments in the maint.ini file suggest that it removes nodes marked down, but is it possible that with weekly nodelists, old nodelists with long-dead systems which just disappeared off of later lists will be included in the nodelist browser?

Seems like, I'd want every network to operate similarly to fsxNet. Worse yet, I could have sworn somewhere in setting things up, I saw a setting for this somewhere but I cannot find it for the life of me.

Or this is set in the .TIC file, like "Overwrite anything old?" I am having trouble recalling.

[Question]: Can anyone provide some guidance for how to deal with nodelists piling up, as per above? Refresh my memory of where this / how it works?

--- Mystic BBS v1.12 A47 2021/09/24 (Linux/64)
* Origin: Shipwrecks & Shibboleths [San Francisco, CA - USA] (21:1/227)

[Question]: Can anyone provide some guidance for how to deal with nodelists piling up, as per above? Refresh my memory of where this /

Just after this message was sent, I found it:

; If this is true, then Mystic will allow the REPLACE TIC option, which will
; remove and replace files by the specified file mask.

allow_replace = true

OK, so I assume, since I have this set up for everything, that just isn't in the .TIC file as I suspected.

--- Mystic BBS v1.12 A47 2021/09/24 (Linux/64)
* Origin: Shipwrecks & Shibboleths [San Francisco, CA - USA] (21:1/227)

On 26 Oct 2021, DustCouncil said the following...

[Question]: Can anyone provide some guidance for how to deal with nodelists piling up, as per above?

So I've been giving this some thought. I prefer the way fsxNet deals with this as well. I'm not really sure I need every nodelist ever hanging around for time and eternity.

Sure, there may some fascination down the line to know what the nodelist looked like the 2nd week of August back in <insert year here>, but there may be other places to scratch that itch. For me I'm not sure I need a couple hundred old nodelists laying around.

I'm considering implementing this:

find /path/to/files/* -mtime +90 -exec echo {} \;

This will show you all files older than 90 days in a particular directory. Replace echo with rm if you want to delete those files. Use at your own risk.

Combined with running this in mutil:

[General]
PackFileBases = true

[PackFileBases]
check_files = true
remove_missing = true


It seems like it may be a good way to get rid of older files in your file bases, unless someone has a more elegant solution?


Jay

... Never invest your money in anything that eats or needs painting.

--- Mystic BBS v1.12 A47 2021/10/25 (Raspberry Pi/32)
* Origin: Northern Realms (21:3/110)

[Question]: Can anyone provide some guidance for how to deal with nodelists piling up, as per above?

I thought of doing just this myself. I guess I was curious why nodelists are distributed the way they are (i.e. not like fsxNet); maybe the whole idea is that SysOps can manage them how they like.

I am curious about the way the Nodelist Browser parses them. If I have 10 years of them, is it processing any and all going ten years back, because the logs seem to suggest that, and:

1. If a node number is reassigned, such that multiple boards have been assigned the same node number over time, what happens then (presumably the last file processed, or the newest file, overrides the old)?

2. If a node number is retired because a board goes down, will that nonetheless remain in the Nodelist Browser?

For hysterical porpoises, it would seem to make more sense to have a file echo like HISTORICAL_NODELISTS and then another for CURRENT_NODELIST if indeed people want to save the old nodelists.

But I'm just trying to understand the logic looking at it as a n00b.

Part of my prejudice is whenever I have some kind of trouble or weirdness I look at fsxNet conventions and wonder why it isn't working like fsxNet (for me, *everything works and is as expected* in fsxNet. It is...orderly.)

--- Mystic BBS v1.12 A47 2021/09/24 (Linux/64)
* Origin: Shipwrecks & Shibboleths [San Francisco, CA - USA] (21:1/227)

On 26 Oct 2021 at 11:15p, DustCouncil pondered and said...

Part of my prejudice is whenever I have some kind of trouble or
weirdness I look at fsxNet conventions and wonder why it isn't working like fsxNet (for me, *everything works and is as expected* in fsxNet.
It is...orderly.)

Phew :)

Nodelist in FTN are usually created with a day number as the extension so up
to .365 and then if they are zipped they have a *.ZNN format with NN equating to something related to the day number (from memory)

As someone noted the nodelists that are hatched in fsxNet are shipped with
TIC files that contain the REPLACE verb in them. Systems that honour that
will replace the old file with the incoming one... which is why you (usually) see only one fsxNet nodelist in the FSX_NODE file echo at any one time.

Mystic Nodelist browser reads nodelist.txt file from data dir.. this is
created when MUTIL runs the merge nodelist stanza

MUTIL can happily compare more than one nodelist to figure out the latest and will then include that in the nodelist.txt file the Mystic browser will look at.

So if you wanted to you could periodically purge some old nodelists if you wished or just let MUTIL chug through them all.

--- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)