src/sbbs3 scfgsave.c 1.91 1.92
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv1577

Modified Files:
scfgsave.c
Log Message:
smb_open_sub() will now create the msgbase if hasn't been created yet.

I noticed that more than one caller of smb_open_sub() would not call smb_create() if the sub had not been previously "created" and in some of the instances where they did call smb_create(), if create failed, the message base was errorneously left open. So just do the create here to elmiinate the chance of error (forgetting) and redundancy of logic.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/sbbs3 scfgsave.c 1.92 1.93
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv4188

Modified Files:
scfgsave.c
Log Message:
Use smb_fgetlength() instead of filelenth(fileno()).


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/sbbs3 scfgsave.c 1.95 1.96
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv14283

Modified Files:
scfgsave.c
Log Message:
Fix bug reported by WitNik (John):
The msgbase 'status' header created with smb_open_sub() had all its fields 0-filled.
This would cause all kinds of msgbase settings (e.g. max msgs, max age, etc.) to not propagate from their SCFG settings (for mail or sub-boards)
to the newly-created msg base(s).
But most importantly, it would cause the mail base to be created without the "EMail" attribute flag, causing the msgbase to be treated as a sub-board (public message area) and users could not then read their received mail.

The root-cause was that smb_open() will zero-out the current smb.status
value before trying to read it from the msgbase header, thus losing any
values that were populated in there before calling smb_open(). Rather than change the behavior of the ancient smb_open() function, just restore the correct default smb.status values after calling smb_open() and before
calling smb_create().


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/04bb1bf85f50d42967a0cd4a
Modified Files:
src/sbbs3/scfgsave.c
Log Message:
Actually save the library's virtual sub-directory naming option value.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/cadada4df5a4752134329947
Modified Files:
src/sbbs3/scfgsave.c
Log Message:
Fix issue with QWKnet hub sub-board mappings when inserting new sub-boards

The sub_t.subnum's that were being updated as message areas were being saved to msgs.ini could not be used as an index into the scfg_t.sub array at this point (the subnum would be the new index position when the msgs.ini was re-read/loaded)
.

This was not an issue in v3.19 because we just saved the subnum (to msgs.cnf) and
in v3.20, we save the sub's internal code (to msgs.ini) and were using the newly
updated sub_t.subnum to find the corresponding sub_t for that internal code. Since
the subnum is not used now during the save process, no need to update it here (this reverses part of the commit 11e529d40bca40 from 5 years ago).

This fixes issue #502 - thanks to the irc.synchro.netizens that reported it!

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/03b1f169ca63ad0c3f602f8f
Modified Files:
src/sbbs3/scfgsave.c
Log Message:
Fix bug where file.ini min_dspace could be set to -1

min_dspace is an *unsigned* short, so saving 65535 (the default) was converting the signed decimal representation when saving file.ini.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net