-
src/sbbs3/scfgsave.c
From
rswindell@VERT to
CVS commit on Saturday, July 28, 2018 22:27:00
src/sbbs3 scfgsave.c 1.75 1.76
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv31801
Modified Files:
scfgsave.c
Log Message:
When attempting to create message base during config-save, make sure the
full path to the data dir is created first (note: md() calls mkpath()). write_msgs_cfg() will now return FALSE if any message bases couldn't be created, but nobody is checking the return value currently.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Sunday, July 14, 2019 09:01:28
src/sbbs3 scfgsave.c 1.80 1.81
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv16473
Modified Files:
scfgsave.c
Log Message:
Call prep_dir() (before md/mkdir) even when no file storage path is specified.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Sunday, July 14, 2019 09:53:18
src/sbbs3 scfgsave.c 1.81 1.82
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv22685
Modified Files:
scfgsave.c
Log Message:
Refactor the transfer file path (storage directory) creation logic in write_file_cfg(). I'm pretty sure this fixes the bug introduced in r1.75 (Mar-7-2018) where it would use the directory's custom "data dir" as the
parent of the sub-directory even if it was blank.
So if you're like Mark Lewis and you're getting a bunch of sub-directories created in your "ctrl" directory when you save changes in SCFG, this is likely the cause. Only happened if you had both the library's "Parent Directory"
and the "File Transfer Path" of the directory, blank.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Sunday, July 14, 2019 10:02:47
src/sbbs3 scfgsave.c 1.82 1.83
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv25136
Modified Files:
scfgsave.c
Log Message:
Typo in previous commit: SAFECAT, not SAFECOPY!
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Sunday, July 14, 2019 10:10:08
src/sbbs3 scfgsave.c 1.83 1.84
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv26145
Modified Files:
scfgsave.c
Log Message:
Add the "dirs" sub-folder (under data) to the last 2 commits.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Monday, July 15, 2019 02:13:35
src/sbbs3 scfgsave.c 1.84 1.85
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv23467
Modified Files:
scfgsave.c
Log Message:
Fix bug in previous commit (this is getting a bit rediculous). Don't add the "dirs" sub-dir to a sysop-defined directory-specific data directory.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Tuesday, August 06, 2019 20:32:58
src/sbbs3 scfgsave.c 1.87 1.88
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv31731
Modified Files:
scfgsave.c
Log Message:
Fix issue reported by Mark Lewis:
scfg
validates/creates directories when you save the file area config but they are
missing the '/' between "dirs" and the internal code...
So the Transfer File Path auto-default-value logic is actually in 3 places:
- load_cfg.c prep_cfg()
- scfgsave.c write_file_cfg()
- scfgxfr2.c dir_cfg() - for display purposes only
<sigh>
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Sunday, August 02, 2020 07:23:34
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