Hello g00r00!

Welcome back, and I hope you are doing well!

I just wanted to write down these few things that I discovered with 1.12A43 on Linux x64, before I forget them:

* If a file download takes longer time than the inactivity timeout, one gets disconnected immediately after the download. File downloads should not be counted as inactivity?

* Download batches are cleared after downloading, also if you abort a
download. Perhaps this could be detected in some way, at least for the
internal file transfer protocols? Or one could get a prompt after downloading to clear the batch or not?

* Sometimes Ctrl-K ceases to work in the full screen editor, especially after pasting a lot of text. (Don't know if this could have anything to do with the spell checking or similar.)

* If you try to move a file area or message area before another one (/C followed by moving to where you want it and then /M), this doesn't work if
you try to move it to the top. You have to choose #2 in the list and /M
it there, then move down the top entry in a similar fashion.

* If you change a [local, at least] message area to New Scan --> Forced, and then back (e.g. to Yes) again, Mystic appears to stick with the Forced setting. If you e.g. try to remove the area from the list of scanned message areas (Z) from the message menu, Mystic refuses to change its status from Yes to No.

I had to remove the message base files (and also did run MUTIL with the PackMessageBases stanza) to make Mystic realize that Private Messages
shouldn't be New Scan --> Forced any longer.

* If a local message area has New Scan --> Forced (e.g. above) -- e.g. Private Messages -- and you post a local, private message to yourself, check for e-mails, answer Yes to the first prompt to read the messages, and then try to Esc, one is notified that "Private Messages is mandatory reading!" and it refuses to let you exit. However pressing "G" will allow you to exit. Perhaps it shouldn't? Although I was thankful it did allow me to exit when I encountered the Forced problems (above). :-)

* I recently encountered a situation where local, private messages were
flagged as New (N) in the indexed message viewer -- e.g. when checking for e-mails and answering Y to the read prompt -- and reading them doesn't turn
off the N flag (they were flagged "Read" just fine). What controls the N flag in the listing? Perhaps my Private Messages message area was corrupt in some way (see above problems) -- not sure...

* I had a hard time figuring out how to implement a "correct" scanning for
new, personal messages on login. I wanted to scan both for e-mails (local, private, unread messages) and similarly for echomail/netmail messages. I
ended up with the following in my prelogin menu, replacing the stock MC
(Check e-mail) entry, and thought I would post it here for others to try, and perhaps for you to comment if I am doing something wrong. :-)

It has been partially borrowed from the personalscan menu, with some changed options (data).

Command � (MC) Check e-mail
Data � /UNREAD
Access �
Execute � Select

Command � (GT) Display line of text
Data � |CL|01[|10�|01] |09Scanning for new personal messages...|DE|CR|CR
Access �
Execute � Select

Command � (MQ) Message quick scan
Data � /NOSCAN /NOFOOT /NEW /YOU /LIST /NOREAD
Access �
Execute � Select

Command � (-R) Reset OK ACS flags
Data � 0
Access �
Execute � Select

Command � (GT) Display line of text
Data � |CL|01[|10�|01] |09There are no new messages.|DE|DE|CR
Access � !OY
Execute � Select

Command � (-Y) Ask Yes/No (default Yes)
Data � |CR|01[|10�|01] |09You have |11|&3 |09new personal messages(s). Read now? |11
Access � OY
Execute � Select

Command � (MN) Message new scan
Data � /P /G
Access � OK
Execute � Select

Perhaps some of this could make it into future versions of Mystic? As it is now, the stock prelogin menu will show all private messages over and over again (as the /UNREAD flag is missing).

The e-mail check (MC) should probably be unnecessary as the global personal mail scan (MQ) should catch local messages, too, but in some circumstances I encountered situations where local, private messages were found only by MC
and not by MQ, so at the moment I keep both. Better safe than sorry. :-)

I adjusted the corresponding message menu options (C = Check for E-mail and G
= Global Personal Scan, whose actions are really in the "personalscan" menu) similarly.

Hope this helps someone, and looking forward to any input that you (or
anyone else) might have on this! :-)


On my wishlist for future versions would be:

* The ability to mark a message as unread and/or new, if one wants to return
to it later.

* The ability to be able to change the keystroke (/) which pulls up the Editor Commands menu in the full-screen editor. Slashes are common in paths, and I have aborted message posts by accident many times because of slashes. :-)

* The ability to tag all files in a file area without browsing everything
using the indexed file listing.

* ...or at least a keystroke to be able to tag all files (if any) on the current page in the indexed file listing.

* That the indexed file listing should show strictly increasing
file numbers, instead of numbering only the files on each screen (always starting with 1).

* The ability to have more than 50 files in the download batch. Perhaps this
is a limitation imposed by the support for some external file transfer protocols (which could have limitations when it comes to their arguments)?

* The ability to edit users, or at least upgrade users (changes could take effect on next login), even if they are online. New users could be browsing files and messages for hours, and then one easily forgets to upgrade them later...

* A display code which shows how many files the user downloaded in this
session (not in total).

* A display code which shows how many kilobytes the user downloaded during
this session (not in total).

* A semaphore, which, if you create it, will cause MIS to reload its configuration. E.g. after changing events in the event editor or server settings in the server editor.

* ...or perhaps the editors could ask if you would like to reload
configuration immediately (disconnects all users including yourself!), as soon as circumstances allow (no logged in users), or in X minutes (warning
logged-in users and allowing them to disconnect in a controlled fashion).

* A semaphore, which, if created, will cause MIS to exit. Kind of like a BBS event but semaphore-based. This could be an alternative to the above one
(e.g. forcing MIS to exit so that systemctl or similar can restart it automatically).

Thanks again!

Best regards
Zip

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

* If a file download takes longer time than the inactivity timeout, one gets disconnected immediately after the download. File downloads should not be counted as inactivity?

I have a lot of trouble with this. Especially when a user comes in to
download a file from a fTerm or whatever that java-based browser terminal is called. People see something they want and try to download it, only to get frozen on both ends because there's no protocol support. Node just sits there indefinitely. This is one of the reasons I insist on a nightly reboot of *the system*, not just Mystic. The problem exists also on the Windows port.

* A semaphore, which, if created, will cause MIS to exit. Kind of like a BBS event but semaphore-based. This could be an alternative to the above one (e.g. forcing MIS to exit so that systemctl or similar can restart it automatically).

I would second this. There's no way to elegantly shut down MIS elegantly. I
end up having to force quit it on my nightly maintenance. I do not like doing that.

--- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
* Origin: Northern Borderlands: northernborderlands.ddns.net (21:2/107)

Hello Gryvon!

Thank you for your reply!

On 19 Oct 2019, Gryvon said the following...

* If a file download takes longer time than the inactivity timeout, o gets disconnected immediately after the download. File downloads shou not be counted as inactivity?

I have a lot of trouble with this. Especially when a user comes in to download a file from a fTerm or whatever that java-based browser
terminal is called. People see something they want and try to download
it, only to get frozen on both ends because there's no protocol support. Node just sits there indefinitely. This is one of the reasons I insist
on a nightly reboot of *the system*, not just Mystic. The problem exists also on the Windows port.

Thanks, yes, I've also noticed this from fTerm connections. Many times,
looking with tools such as 'strace' to see what the Mystic process (the one handling the active connection) is doing, it displays constans "EIO" errors (I/O error because the remote is in practice not listening any longer,
probably because the user has quit his/her web browser session), and so it loops for ages -- at least for the inactivity timeout, but I've had broken sessions last indefinitely just like you. The "EIO" errors appear to
be intermixed with "gettimeofday" calls (perhaps some timing stuff during
file transfers or some "retry" mechanism).

So some kind of detection for I/O error circumstances inside Mystic
(including its built-in file transfer protocols) would be helpful to
overcome this.

Best regards
Zip

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

Hello g00r00!

Welcome back, and I hope you are doing well!

I just wanted to write down these few things that I discovered with 1.12A43 on Linux x64, before I forget them:

I just had a massive message almost done when I got disconnected and I don't think Gryphon has Mystic's resume post feature set up so I may lost it.

I had originally responded to each of your points here and it was loooonnnggg, so I am not going to do that right now again. But I have taken all of your points and issues into consideration and I have made a note of each of them in my TODO with the exception of maybe one or two that I will re-address below.

In other words I will work on everything except maybe these couple of things that have discussion points:

* The ability to tag all files in a file area without browsing everything using the indexed file listing.

* ...or at least a keystroke to be able to tag all files (if any) on the current page in the indexed file listing.

I am not sure how I feel about this one only because pressing the space bar
on a file will tag it and automatically advance it, and with descriptions
files are rarely more than a couple on a page anyway meaning space just about functions as you want it to already.

* The ability to have more than 50 files in the download batch. Perhaps this is a limitation imposed by the support for some external file transfer protocols (which could have limitations when it comes to their arguments)?

It was a limit based on old DOS memory limitations. Mystic used to run in like 400kb of memory and it stored the batch in memory only. I do think I want to rebuild the system someday so that the batch queues are stored on disk and they are not per-session, so you can tag stuff and log off and when you come back you'll have the same queue. Maybe in the meantime I can bump it up to 99 or something for now though.

* The ability to edit users, or at least upgrade users (changes could
take effect on next login), even if they are online. New users could be browsing files and messages for hours, and then one easily forgets to upgrade them later...

This is available in Windows, but its not in Linux because there is no local console. In other words, to do so will require quite a bit of work and it is on my TODO list already though. I cannot say when I will get to it but I
will move it more towards the top of the list since its being requested. Its probably going to be a limited editor compared to the traditional user editor. I will add this to the list.

* A semaphore, which, if created, will cause MIS to exit. Kind of like a BBS event but semaphore-based. This could be an alternative to the above one (e.g. forcing MIS to exit so that systemctl or similar can restart it automatically).

If you send it a SIGTERM it should shut down automatically and gracefully.
But I will add this to the TODO list as a possible option that can be implemented outside of Unix-based triggers.

* That the indexed file listing should show strictly increasing
file numbers, instead of numbering only the files on each screen (always starting with 1).

I do not wish to do this for a few reasons, the first is that number can get quite large. There are some people who have more than 10,000 files in a single base for whatever reasons, for example. We only have 79 characters to fit a lot of detail (or 40 characters if you made a super retro theme) so keeping it per page allows this to take a small amount of screen real-estate.

Also the idea is that you should be able to jump to files by typing the number on the page, and typing "1" to jump to a file automatically is much better than typing "16391". I can't remember if I ever finished adding that or not though.

And finally the reason I am probably not going to do that one is it would take a surprisingly big amount of code change to do it.

Everything else you mentioned are things that I plan to do.

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Cyberia BBS | cyberiabbs.zapto.org | San Jose, CA (21:1/120)

* A semaphore, which, if created, will cause MIS to exit. Kind of lik BBS event but semaphore-based. This could be an alternative to the ab one (e.g. forcing MIS to exit so that systemctl or similar can restar automatically).

I would second this. There's no way to elegantly shut down MIS
elegantly. I end up having to force quit it on my nightly maintenance. I do not like doing that.

Yep there is in Linux but not in Windows. I will look into building
something to bridge that gap!

terminal is called. People see something they want and try to download
it, only to get frozen on both ends because there's no protocol support. Node just sits there indefinitely. This is one of the reasons I insist

There should be a timeout that kicks back to the BBS after like 60 seconds or something, if the terminal is not triggering the transfer protocol. If that
is not working then thats certainly something that needs to be corrected!

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Cyberia BBS | cyberiabbs.zapto.org | San Jose, CA (21:1/120)

Thanks, yes, I've also noticed this from fTerm connections. Many times, looking with tools such as 'strace' to see what the Mystic process (the one handling the active connection) is doing, it displays constans "EIO" errors (I/O error because the remote is in practice not listening any longer, probably because the user has quit his/her web browser session), and so it loops for ages -- at least for the inactivity timeout, but
I've had broken sessions last indefinitely just like you. The "EIO"
errors appear to be intermixed with "gettimeofday" calls (perhaps some timing stuff during file transfers or some "retry" mechanism).

This is good to know. There is clearly an issue here that needs to be looked into. Is this with Zmodem or any protocol in particular? I don't know how I can test with fTerm but I would like to do so.

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Cyberia BBS | cyberiabbs.zapto.org | San Jose, CA (21:1/120)

Hello g00r00!

Thank you for your reply!

On 25 Oct 2019, g00r00 said the following...

I just had a massive message almost done when I got disconnected and I don't think Gryphon has Mystic's resume post feature set up so I may
lost it.

I've also had that happen! :)

Everything else you mentioned are things that I plan to do.

I'm very glad to hear that! :)

Thanks again for all the work you have put (and are putting) into Mystic. it
is much appreciated!

Best regards
Zip

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

Hello g00r00!

Thank you for your reply!

On 25 Oct 2019, g00r00 said the following...

one handling the active connection) is doing, it displays constans "E errors (I/O error because the remote is in practice not listening any

This is good to know. There is clearly an issue here that needs to be looked into. Is this with Zmodem or any protocol in particular? I
don't know how I can test with fTerm but I would like to do so.

I have at least seen it with QWK downloads, I believe Zmodem, yes.

If you'd like, feel free to use fTerm from https://scbbs.nsupdate.info/, register for a new account, and select all fsxNet message areas for new scan, then download the 20 MB or so resulting QWK ZIP file using Zmodem and close
the web browser, then notify me in some way, and I'll check if the
process is "hanging" and, if so, collect an strace dump for you.

Best regards
Zip

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)