This is an old revision of the document!
.cnf files
.cnf
files are proprietary binary configuration files located in the ctrl
directory and node
directories and are maintained using the SCFG utility.
Auto-backup
SCFG features an auto-backup system controlled with the SCFG -b#
command-line option to specify the backup level. -b5
is the default, providing for 5 backups of each file modified. -b0
disables the auto-backup feature.
.cnf
files ending with .0.cnf
represent the most recent backup of the .cnf
file, .1.cnf
the next to most recent backup, etc.
The oldest backup files (e.g. *.5.cnf
when the backup level is 5) are automatically removed (deleted).
Individual files
The various .cnf files are:
chat.cnf
: This contains the Chat Features settings from SCFG specifically the Guru, Multinode chat actions and channels, and external sysop pages. This is unused on most BBSs and may be removed from or integrated with the ircd in version 4.file.cnf
: Contains the file library and directory configuration from File Areas and the file transfer configuration from File Optionsmsgs.cnf
: Contains the message groups and sub-boards configured via Message Areas, Message Options, and Networksxtrn.cnf
: Contains the External Programs configuration which includes events, external editors, hot-key events and doorsnode.cnf
: Located in the NODE Directories, and configured via the Nodes menu, it is expected that only the node config which corresponds to the FirstNode value (usually 1) insbbs.ini
is actually used, but there may be times with some tools that a different node config file is used. Because of this, it is recommended that a sysop ensure that allnode.cnf
files for the same instance are configured identically.
Development Notes
These files were originally a text-based configuration but were converted to binary for efficiency reasons which no longer apply. In some future version of Synchronet, these files will be converted to a text format, most likely .ini files.
The multiple node.cnf
files need to be replaced by a single file which configures all the nodes for a specific instance of Synchronet. Currently, this means supporting the <base>.<host|os>.<ext>
format because the assumption that the only reason to run multiple instances is that there are multiple systems is currently baked in.