under linux, how do you update the ctrl dir. without overwrite the *.cfg or *.ini or the *.cnf or the guru.dat files?
under linux, how do you update the ctrl dir. without overwrite the *.cfg or *.ini or the *.cnf or the guru.dat files?
The idea of the ctrl directory is to contain files that are *all* particular to your BBS and it's configuration. So you wouldn't be expected to "update" it from stock/default files at any time.
good to put the new entries in your own text.dat file? What happens if you update your Synchronet binaries and are missing some of the new entries in text.dat? Does Synchronet use default values?
Re: question
By: Digital Man to Lord Time on Thu Dec 14 2017 12:24 am
The idea of the ctrl directory is to contain files that are *all* particular to your BBS and it's configuration. So you wouldn't be expected to "update" it from stock/default files at any time.
I imagine that when new entries are added to ctrl\text.dat, it's probably good to put the new entries in your own text.dat file? What happens if you update your Synchronet binaries and are missing some of the new entries in text.dat? Does Synchronet use default values?
When I see that text.dat has some new entries, usually I'll copy the new entries into my own text.dat so that at least I'll see them there in case I want to customize those entries.
Re: question
By: Nightfox to Digital Man on Thu Dec 14 2017 09:31 am
good to put the new entries in your own text.dat file? What happens if you update your Synchronet binaries and are missing some of the new entries in text.dat? Does Synchronet use default values?
it gives an error msg or it shits itself.
if you update your Synchronet binaries and are missing some of the new entries in text.dat? Does Synchronet use default values?
it gives an error msg or it shits itself.
Not since v3.15.
The idea of the ctrl directory is to contain files that are *all*
particular to your BBS and it's configuration. So you wouldn't be
expected to "update" it from stock/default files at any time.
under linux, how do you update the ctrl dir. without overwrite the *.cfg or *.ini or the *.cnf or the guru.dat files?
Re: questionexpected
By: Digital Man to Lord Time on Thu Dec 14 2017 12:24 am
The idea of the ctrl directory is to contain files that are *all* particular to your BBS and it's configuration. So you wouldn't be
goodto "update" it from stock/default files at any time.
I imagine that when new entries are added to ctrl\text.dat, it's probably
to put the new entries in your own text.dat file? What happens if you update your Synchronet binaries and are missing some of the new entries in text.dat?
Does Synchronet use default values?
When I see that text.dat has some new entries, usually I'll copy the new entries into my own text.dat so that at least I'll see them there in case I want to customize those entries.
.ini or .cfg or .conf) and verify you didn't actually make any changes (or any changes that you care about) and then over-write just *those* files from a download from CVS or vert (e.g. sbbs_run.tgz). If you do a directory comparision (between cvs and your local directory) you might find some *new* files in CVS and it would be safe to copy those over since you won't be over-writing anything of your own.
Re: question
By: Digital Man to Nightfox on Thu Dec 14 2017 05:24 pm
The idea of the ctrl directory is to contain files that are *all* DM>> particular to your BBS and it's configuration. So you wouldn't be DM>> expected to "update" it from stock/default files at any time.
I thought that was the purpose of the mods directory, did I miss something along the way?
Re: question
By: Digital Man to Lord Time on Thu Dec 14 2017 12:24 am
.ini or .cfg or .conf) and verify you didn't actually make any changes (or any changes that you care about) and then over-write just *those* files from a download from CVS or vert (e.g. sbbs_run.tgz). If you do a directory comparision (between cvs and your local directory) you might find some *new* files in CVS and it would be safe to copy those over since you won't be over-writing anything of your own.
so i have .cfg files and .ini files with the same prefix. like sockopts.ini and sockopts.cfg.
which is safe to delete?
so i have .cfg files and .ini files with the same prefix. like sockopts.ini and sockopts.cfg.
which is safe to delete?
You can delete sockopts.cfg. Hasn't been used since 2005.
Re: question
By: Digital Man to MRO on Sun Dec 17 2017 12:52 pm
so i have .cfg files and .ini files with the same prefix. like sockopts.ini and sockopts.cfg.
which is safe to delete?
You can delete sockopts.cfg. Hasn't been used since 2005.
so if i have the same files that are cfg and ini i keep the ini, right?
so if i have the same files that are cfg and ini i keep the ini, right?
Probably. What other examples do you have? If you ever ran v4upgrade, you'd have a bunch of converted .ini files that aren't actually used (yet), so in that case, no, don't delete the .cfg files.
Re: question
By: Digital Man to MRO on Sun Dec 17 2017 06:07 pm
so if i have the same files that are cfg and ini i keep the ini, right?
Probably. What other examples do you have? If you ever ran v4upgrade, you'd have a bunch of converted .ini files that aren't actually used (yet), so in that case, no, don't delete the .cfg files.
i never ran any upgrade program, i would just extract the files in the correct dirs.
here's what i have over the years that have this issue:
alias.cfg
alias.ini <- not used in v3
dns_blacklist.cfg
dns_blacklist.ini <- not used in v3
dnsbl_exempt.cfg
dnsbl_exempt.ini <- not used in v3
domains.cfg
domains.ini <- not used in v3
ftpalias.cfg
ftpalias.ini <- not used in v3
mailproc.cfg <- deprecated (not used any longer) in v3
mailproc.ini
Mime_Types.Cfg <- deprecated in v3
mime_types.ini
relay.cfg
relay.ini <- not used in v3
Services.Cfg <- deprecated in v3
services.ini
sockopts.cfg <- deprecated in v3
sockopts.ini
twitlist.cfg
twitlist.ini <- not used in v3
The only explanation I can think of is that someone ran v4upgrade.exe on your system.
Re: question
By: Digital Man to MRO on Sun Dec 17 2017 07:57 pm
The only explanation I can think of is that someone ran v4upgrade.exe on your system.
could it be because i downloaded these files from the cvs?
i didnt even know of v4upgrade.exe
a lot of them are dated 08-07-2012 (sometimes both files)
i didnt even know of v4upgrade.exe
a lot of them are dated 08-07-2012 (sometimes both files)
Sounds like someone ran it on that date. <shrug>
Sysop: | Kurt Hamm |
---|---|
Location: | Columbia, SC |
Users: | 8 |
Nodes: | 20 (0 / 20) |
Uptime: | 135:59:49 |
Calls: | 2,804 |
Calls today: | 1 |
Files: | 64 |
Messages: | 854,509 |