• 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