Closed x-tec2017 closed 6 years ago
Troubleshot problem. Cause: The d.u/d directories are stored in seq files which are loaded into arrays upon entering a specific UD library. This consumes memory. The out of memory or board crash occurs upon executing the upload or download function and as the mini modules load either im.trans or im.disp they consume more memory which could cause the above issue. The PR command could also cause the issue as it loads it's im. module if not enough memory remains to hold it. Solution #1: (Implemented on the wifi BBS) 1. Reduced the maximum number of entries in the UD directories to 30. Doing so prevents the PR command from overflowing memory. 2. Eliminated code for loading im.disp and im.trans, the purpose of which is to provide a display on the sysop's screen as to the status of the upload or download. While the sysop display is a "nice to have" feature, it is not necessary for providing functionality to file transfers. Eliminating the screen changes resulted in successful test uploads and downloads in a UD library containing 30 entries. Protection is provided for not allowing more than 30 uploads in both local and online modes. Solution #2: (Theoretical) Change the file structure of the UD directories from sequential to relative and eliminate loading the entire directory into arrays. Instead, display directories by calling to record numbers in the rel file directories. This solution would be more modern and could possibly allow a full 60 entries in the directories as memory usage to display record entries, one at a time, would be minimal. It might also preserve the "nice to have" sysop screen displays.
It would appear that it's a gross memory issue, and not related specifically to file lists. Try reading the help inside the editor. Once you get halfway through the MCI commands section, you're essentially out of memory and the BBS crawls.
Reading the help file inside the editor simply displays a seq file (s.menu 3) and does not consume any memory. The UD (and SB) memory issue has already been addressed in release 2 by limiting the number of directory entries to 30. This issue is closed. All participants in evaluating Image 2.0 should be using the Release 2 version and a new project needs to be opened pertaining to release 2.
@ThaDoctor72 , do you mean .Get File s.menu 3?
Probably not related to any recent changes. The same issue occurs on unmodified Image 2.0 on WN2.