Subj : Re: Badareas.lst location To : Gamgee From : Digital Man Date : Thu Sep 25 2025 13:35:11 Re: Re: Badareas.lst location By: Gamgee to Digital Man on Thu Sep 25 2025 01:51 pm > DM> Yes in theory, SCFG could read the sbbsecho.ini file to find whatever > DM> path/filename the sysop chose to name that file. However, a sysop can > DM> create/use multiple sbbsecho configuration files (they don't have to be > DM> ctrl/sbbsecho.ini), so SCFG wouldn't magically know how to find any > DM> other non-default SBBSecho config files. > > That seems a pretty niche use-case - I'd guess that VERY few sysops are > using multiple sbbsecho.ini files. If somebody *was*, then yes I could > see how they might need to type in a new value in the input dialog to > import that badareas.lst into SCFG. But for the other 99% ...? To be > fair - I see ZERO reason to change it from the default location anyway. If a sysop had multiple sbbsecho config files and they all used the default badareas.lst file path (which seems unlikely), then the sysop would not need to type in a new value if/when importing that badareas.lst file into SCFG. I only mentioned the sbbsecho.ini file issue because it means that desired/expected behavior is that the bad area file path is pulled from that file automatically, but there's really no way for SCFG to know what sbbsecho config file path/filename that SBBSecho is *actually* using. > I guess my question then is - does the location specified in > sbbsecho.ini for the badareas.lst file actually make that file get > created/updated in the location specified? Yes. > Or will it always go to ../data ? No, the path/filename set in sbbsecho.ini is what SBBSecho (or at least the instance that runs with that config file) will update/write when messages for bad area-tags are received. -- digital man (rob) Synchronet "Real Fact" #113: Weedpuller "Assassin" http://youtu.be/opw9RPUOcv8 Norco, CA WX: 80.5øF, 50.0% humidity, 6 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.29-Linux * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705) .