Subj : src/sbbs3/jsexec.c To : Git commit to main/sbbs/master From : Rob Swindell (on Windows) Date : Tue Aug 08 2023 17:43:51 https://gitlab.synchro.net/main/sbbs/-/commit/40995ce1868fdb8cdbacf2a6 Modified Files: src/sbbs3/jsexec.c Log Message: Insure the exec_dir is *always* prepped (fix for Windows upgrade to v3.20)A "prepped" means directory means a relative path from the configuration files(or default settings) has been converted to a full/absolute path with properslashes for the platform (i.e. backslashes instead of forward-slashes onWindows).JSexec doesn't require that the new v3.20 ctrl/*.ini files exist to run; thiswas necessary to be able to run 'jsexec update -> upgrade_to_v320.js' whichdoes the ctrl/*.cnf to .ini file conversion (egg not required to buildchicken). When JSexec failed to load ctrl/msgs.ini(e.g. "!ERROR loading configuration files: 2 (No such file or directory)opening /sbbs/ctrl\msgs.ini"), it would continue to run, but not "prep" anyof the "path" settings (e.g. exec_dir).The first run of 'jsexec update.js' would fail to run upgrade_to_v320.exe(which does the v3.20 user base conversion) and a bunch of other (but not asimportant) update steps because Windows couldn't execute "../exec/*".Multiple errors would be displayed in this case, but the most important (asreported by Ree in #synchronet of irc.synchro.net) was: '..' is not recognized as an internal or external commandright after the status output: No v3.20 user base found, running ../exec/upgrade_to_v320Notice the "../exec/" prefix, which is not support by Windows when specifyinga file path to execute.A second run of 'jsexec update' would work fine because the new v3.20 .inifiles would be successfully created after the first run (though the user basewas not).This is likely the same issue that MRO reported recently when upgrading aWindows SBBS v3.19 install to v3.20 and not having the user base upgradedthe first time. --- SBBSecho 3.20-Linux * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705) .