Hey g00r00,

Looks like after upgrading to a37 I end up with a bunch of random .bsy files in
my /mystic/echomail/out/<network>/ directories and mutil hangs on the busy status and won't complete. I have to manually fidopoll killbusy every time I import or export
messages.

I noticed in the whats.new that there was some work done regarding failure to clean up those .bsy files - looks like in my case, things were made worse :( I am on linux, 64 bit, debian 9. Thanks for all the hard work!

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

I noticed in the whats.new that there was some work done regarding
failure to clean up those .bsy files - looks like in my case, things
were made worse :( I am on linux, 64 bit, debian 9. Thanks for all the hard work!

There was a typo in a file extension, but that change was made weeks ago and has been tested on FSX hub which is stupid active, so this probably isn't a general issue that everyone is seeing. This means questions!

How are you running fidopoll and mutil? Are you doing it manually or with events or crontab? Who owns the busy files? Who owns fidopoll, mutil, etc?
Do you use the MIS BINKP server or just fidopoll?

--- Mystic BBS v1.12 A37 2017/12/13 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)

On Thursday, December 14, 2017 at 8:51:18 AM UTC-8, g00r00 wrote:

I noticed in the whats.new that there was some work done regarding
failure to clean up those .bsy files - looks like in my case, things were made worse :( I am on linux, 64 bit, debian 9. Thanks for all the hard work!

There was a typo in a file extension, but that change was made weeks ago and has been tested on FSX hub which is stupid active, so this probably isn't a general issue that everyone is seeing. This means questions!

How are you running fidopoll and mutil? Are you doing it manually or with events or crontab? Who owns the busy files? Who owns fidopoll, mutil, etc? Do you use the MIS BINKP server or just fidopoll?

Hey g00r00, thanks for the reply :)

I'll answer inline:
How are you running fidopoll and mutil?
- I have events configured to run on semaphores for outbound mail, and on hourly jobs for attempting to get inbound mail. When I noticed I was no longer getting mail, I ran mutil from a shell, and that's where I noticed the .bsy issue.
Are you doing it manually or with events or crontab?
- Via events for outbound (semaphore detections) and hourly event jobs for inbound mail checking. I also did script it as a cronjob briefly, but clearly that's stuck as well :)
Who owns fidopoll, mutil, etc?
- BBS user recursively owns /mystic/*. It's worth mentioning I launch as the BBS user and not as root. Root has not touched anything at all here. I bind to non-exclusive ports so launching as a standard user is not a problem.
Who owns the busy files?
BBS user owns the busy files. If I do 'find /mystic -iname *.bsy' before running mutil, the only .bsy file is /mystic/sempaphore/mis2.bsy. If I look for
.bsy files right after running mutil (when it gets stuck) I end up with the following .bsy files:
./semaphore/mutil.bsy
./semaphore/mis2.bsy
./echomail/out/cybernet.028/00c80001.bsy ./echomail/out/amiganet.027/03860000.bsy
./echomail/out/fidonet/00020064.bsy
./echomail/out/retronet.050/03060000.bsy
They are all owned by my BBS user. If I manually delete the .bsy files in the ./echomail/out/*/ directories, the job completes. Then, the next time I run mutil, the exact same files are created.

It's worth mentioning that these are being created when I run mutil against my inbound mail .ini configuration file.

Do you use the MIS BINKP server or just fidopoll?
- I'm using mis2, but I'm using that as my binkp server.

Thanks g00r00!

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 12/14/17, Ryan Fantus pondered and said...

Hey g00r00, thanks for the reply :)

Hi Ryan.

Good to see you guys have connected, looks like via Fidonet <> alt.bbs.mystic Usenet group :)

g00r00 I queried the ownership stuff as well.

Ryan - what version of A37 are you running? MIS2 was depreciated and became
MIS so I wonder if that's the issue?

Best, Paul

--- Mystic BBS v1.12 A37 2017/12/13 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)

On Thursday, December 14, 2017 at 10:03:14 AM UTC-8, Ryan Fantus wrote:

On Thursday, December 14, 2017 at 9:45:09 AM UTC-8, Paul Hayton wrote:

On 12/14/17, Ryan Fantus pondered and said...

Hey g00r00, thanks for the reply :)

Hi Ryan.

Good to see you guys have connected, looks like via Fidonet <>

alt.bbs.mystic

Usenet group :)

g00r00 I queried the ownership stuff as well.

Ryan - what version of A37 are you running? MIS2 was depreciated and became MIS so I wonder if that's the issue?

Best, Paul

Hm, interesting. I'll give mis a shot. I'm running 1.12a37, which I upgraded

from 1.12a36 (which was a fresh install). I missed the bit about mis2 being deprecated :)

Quick follow-up - no dice, using mis instead of mis2 results in the same problems.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Thursday, December 14, 2017 at 9:45:09 AM UTC-8, Paul Hayton wrote:

On 12/14/17, Ryan Fantus pondered and said...

Hey g00r00, thanks for the reply :)

Hi Ryan.

Good to see you guys have connected, looks like via Fidonet <> alt.bbs.mystic Usenet group :)

g00r00 I queried the ownership stuff as well.

Ryan - what version of A37 are you running? MIS2 was depreciated and became MIS so I wonder if that's the issue?

Best, Paul

Hm, interesting. I'll give mis a shot. I'm running 1.12a37, which I upgraded from 1.12a36 (which was a fresh install). I missed the bit about mis2 being deprecated :)

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Quick follow-up - no dice, using mis instead of mis2 results in the same

problems.

Some weird things here -

In /mystic/data there is a file, ge.mem. It is full of entries like this: d:\code\ge\ge.exe mis_help
Heap dump by heaptrc unit
26 memory blocks allocated : 2755035/2755144
26 memory blocks freed : 2755035/2755144
0 unfreed memory blocks : 0
True heap size : 491520
True free heap : 491424
Should be : 491520

I also notice my dos doors have stopped working. So, I decided to go for a fresh install. Dos doors are still broken. Working on message nets shortly :(

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

./semaphore/mis2.bsy
- I'm using mis2, but I'm using that as my binkp server.

There is no such thing as MIS2, it was removed maybe 40 builds ago. :)

You have a mix match of old vs new versions of Mystic and that is particularly bad to do with A37 because it had data file format changes. It also means the busy change (which was just correcting a typo in a filename) is unrelated.

So lets start here: Make sure you have all of the latest binaries and none of the old ones... This is not limited to only MIS/MIS2 but all of the binaries - please double check them.

After they are double checked, we should probably validate the binaries are all set to the proper user/group and chown -R everything in the Mystic directory structure to that user/group. Finally do a "fidopoll killbusy all" so we're starting with a clean slate with no residue (validate that with your find command).

Keep an eye on the access rights, particularly directory ownership of temp directories, and especially if you deleted mis and kept mis2 on your disk while you ran mis2. During mis2 development there were a couple of things that could cause it to start creating files and directories with the wrong access.

Once this is all done try going through everything manually, starting with running fidopoll the same way your event would execute it. Check for BSY files after it runs, or note obviously if it crashes or something. Since you say
you can reproduce this every time, it should be obvious where the problem occurs when you execute through the steps manually.

--- Mystic BBS v1.12 A37 2017/12/13 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)

I also notice my dos doors have stopped working. So, I decided to go for
a fresh install. Dos doors are still broken. Working on message nets shortly :(

Is DOSEMU complaining about security? Doors saying they cannot access files? If so, it could be that MIS2 was accidentally running as root for a long time, and now its not.

ge.mem is just a memory trace of GE.exe which is my SDL-based ANSI editor called Genesis Engine that has existed for like 15 years now unreleased. I
use it to edit Mystic's ANSI files or prototype UI stuff and what you see is just residue of that.

--- Mystic BBS v1.12 A37 2017/12/13 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)

Hey g00r00,

Thanks for the help. In a moment of frustration and desperation I wiped everything out and reinstalled a37 from scratch. I was still running into these
issues with configuration, so I blew it away and reverted completely to a36. Now things are happy once
again. That said, I'm using mis2, with a36, as it includes an ssh server...is this unsupported?

DOSEMU was not complaining about security, in fact none of the complaints were related to security or ownership. DOSEMU complained about not being able to figure out character sets (cp437, auto, us, etc) and being confused at launch. Reverting back to
a36 mysteriously fixed all of this. I'm not really sure why all these things felt so messed up on my BBS. Perhaps I did something wrong. But a fresh install
had the same problems, which is a bit puzzling.

So...any plans to port Genesis Editor to linux? :D

Anyway, a36 works well for me, so I'll stay on that for the time being. Thanks!

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Ryan Fantus wrote to Paul Hayton <=-

Hm, interesting. I'll give mis a shot. I'm running 1.12a37, which I upgraded from 1.12a36 (which was a fresh install). I missed the bit
about mis2 being deprecated :)

Sounds like the reply I was going to give :) So are we not to use mis2 anymore?

... File not found. Should I fake it? (Y/N)
___ MultiMail/Linux v0.50

--- Mystic BBS/QWK v1.12 A37 2017/12/13 (Raspberry Pi/32)
* Origin: How about a piece of Pi? (1:116/18)

* An ongoing debate between robert wolfe and Ryan Fantus rages on ...

Hm, interesting. I'll give mis a shot. I'm running 1.12a37, which
I upgraded from 1.12a36 (which was a fresh install). I missed the
bit about mis2 being deprecated :)

Sounds like the reply I was going to give :) So are we not to use
mis2 anymore?

MIS2 was deprecated as of v1.12 A36. Use MIS ONLY after installing A36 :) The updated MIS.Exe in A36 is a renamed version of MIS2.Exe and operates the same.


.- Keep the faith, --------------------------------------------------.
| |
| Ben aka cMech Web: http|ftp|binkp|telnet://cmech.dynip.com |
| Email: fido4cmech(at)lusfiber.net |
| Home page: http://cmech.dynip.com/homepage/ |
| | `-------- WildCat! BBS 24/7 +1-337-984-4794 any BAUD 8,N,1 -------'

... Zen football: A long pass out of the I formation.
--- GoldED+/W32-MSVC v1.1.5-b20170303 + Mystic BBS v1.12 A36
* Origin: FIDONet - The Positronium Repository (1:393/68)

again. That said, I'm using mis2, with a36, as it includes an ssh server...is this unsupported?

Well you can do whatever you want :)

But I can't support a mix and match of old versions of Mystic that may or may not be compatible with each other, have known issues, etc. A36 doesn't even have a MIS2 so I don't know what you're actually using lol.

I get that you also need a working BBS too, so I understand why you're back to the old version. But I can't address or help or resolve anything if I don't have the person who has the problem around to help me. I can't send you a new binary with a fix if you're not at the current release level, etc.

DOSEMU was not complaining about security, in fact none of the
complaints were related to security or ownership. DOSEMU complained
about not being able to figure out character sets (cp437, auto, us, etc)

I'm not super familiar with DOSEMU but if the error is that it can't read its configuration to get the default character set, then I would think that could be very possibly be related to security.

Most earlier copies of test-release MIS2 (before it had all of the servers fully functional) had an issue where in some cases it wasn't dropping its root access after port binding...

If you happen to build and test your BBS with that server exclusively, and then switch to the "stable" version which doesn't have that issue, I think it would cause all sorts of random shit to go wrong.

As far as the BSY files, the FSXNET hub gets hammered and really tests this stuff hard. There are times when all 16 incoming BINKP nodes are active at once receiving mail while there is also outbound BINKP and echomail tossing all happening in harmony...

My point is that if it was a general issue like BSY files not getting deleted, then the entire network would halt within minutes of deploying the server. Thee would also be a LOT of people reporting the same issue, and so far its only you.

The only other commonality between being unable to delete a BSY file and a piece of software not reading its configuration values in my mind, would be something with security either on the admin side or the software side.

--- Mystic BBS v1.12 A37 2017/12/13 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)

Quick follow-up - the a36 build I was using was a pre-alpha, hence why the mis2
was hanging around. Ugh...looks like I have to do more bbs maintenance to get up to real a36.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Thanks for the reply, once again :)

On Friday, December 15, 2017 at 1:57:52 PM UTC-8, g00r00 wrote:

again. That said, I'm using mis2, with a36, as it includes an ssh
server...is this unsupported?

Well you can do whatever you want :)

I wasn't saying that to be flippant. A bog standard 112a36 64 bit linux package
installed both mis and mis2, and I was using mis2 because it included ssh. I had no idea that it was unsupported. Standard mis looks like the old mystic server.

But I can't support a mix and match of old versions of Mystic that may or may not be compatible with each other, have known issues, etc. A36 doesn't even have a MIS2 so I don't know what you're actually using lol.

I get that you also need a working BBS too, so I understand why you're back

to

the old version. But I can't address or help or resolve anything if I don't have the person who has the problem around to help me. I can't send you a

new

binary with a fix if you're not at the current release level, etc.

I can try to repro, I guess. It may be a minimal cost for me to rent additional
server space temporarily while we figure this out. I'll mull that over tonight and more than likely will just pull the trigger on getting another box.

DOSEMU was not complaining about security, in fact none of the complaints were related to security or ownership. DOSEMU complained about not being able to figure out character sets (cp437, auto, us, etc)

I'm not super familiar with DOSEMU but if the error is that it can't read its configuration to get the default character set, then I would think that could be very possibly be related to security.

I don't remember the precise log lines, since I went nuclear and blew everything away and just started over. I'll see if I can reproduce the issue.

Most earlier copies of test-release MIS2 (before it had all of the servers fully functional) had an issue where in some cases it wasn't dropping its

root

access after port binding...

If you happen to build and test your BBS with that server exclusively, and

then

switch to the "stable" version which doesn't have that issue, I think it

would

cause all sorts of random shit to go wrong.

I never ran anything mystic related as root. I always bound to nonprivileged ports and ran everything as my BBS user.

As far as the BSY files, the FSXNET hub gets hammered and really tests this stuff hard. There are times when all 16 incoming BINKP nodes are active at once receiving mail while there is also outbound BINKP and echomail tossing

all

happening in harmony...

My point is that if it was a general issue like BSY files not getting

deleted,

then the entire network would halt within minutes of deploying the server.

Thee

would also be a LOT of people reporting the same issue, and so far its only you.

I could've sworn the fsx hubs were Windows machines, but I could be wrong. Like
I said, I'll try to repro, something got into a funky state and I'm not sure why. *shrug*

The only other commonality between being unable to delete a BSY file and a piece of software not reading its configuration values in my mind, would be something with security either on the admin side or the software side.

Yeah, agreed, and that's what my thought process was as well. However, root never did anything, there is only one user account, and the directory and all files were explicitly owned by the bbs user at all times. Dunno man. :P

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

I wasn't saying that to be flippant. A bog standard 112a36 64 bit linux package installed both mis and mis2, and I was using mis2 because it included ssh. I had no idea that it was unsupported. Standard mis looks like the old mystic server.

If you have some copy of A36 that has mis and mis2 then you don't have a real copy of A36. Not sure if you knew that beforehand or not, but the legit copy of A36 will only have the server and nothing else. No mis2, no old looking server. Just mis (the server formally known as mis2).

You can download the A36 release at mysticbbs.com/downloads if you need it.

I can try to repro, I guess. It may be a minimal cost for me to rent additional server space temporarily while we figure this out. I'll mull that over tonight and more than likely will just pull the trigger on getting another box.

Are you able to install another copy in a separate directory so you can do some testing with the new version? I'm not sure how your server works, but if its by space then a fresh Mystic only takes 3 megabytes. You could just use different ports if you wanted to run any of the servers.

If you can do a side install we could use the latest in-progress A37 from www.mysticbbs.com/downloads/prealpha, and we can work with that until we resolve things with DOSEMU, etc.

I could've sworn the fsx hubs were Windows machines, but I could be
wrong. Like I said, I'll try to repro, something got into a funky state and I'm not sure why. *shrug*

Yes the main hub is Windows but the mailer's logic and code doesn't change between operating system versions. The Linux version is probably more heavily used than the Windows version in general.

--- Mystic BBS v1.12 A37 2017/12/15 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (1:129/215)

Ben Ritchey wrote to Warp 4 <=-

Hm, interesting. I'll give mis a shot. I'm running 1.12a37, which
I upgraded from 1.12a36 (which was a fresh install). I missed the
bit about mis2 being deprecated :)

Sounds like the reply I was going to give :) So are we not to use
mis2 anymore?

MIS2 was deprecated as of v1.12 A36. Use MIS ONLY after installing A36
:) The updated MIS.Exe in A36 is a renamed version of MIS2.Exe and operates the same.

Now someone tells me, but it looks like there was no harm done.

... A bit like trying to stuff sausage casings with living animals.
___ MultiMail/Linux v0.50

--- Mystic BBS/QWK v1.12 A37 2017/12/13 (Raspberry Pi/32)
* Origin: How about a piece of Pi? (1:116/18)

./semaphore/mis2.bsy
- I'm using mis2, but I'm using that as my binkp server.

There is no such thing as MIS2, it was removed maybe 40 builds ago. :)

You have a mix match of old vs new versions of Mystic and that is particularly bad to do with A37 because it had data file format changes. It also means the busy change (which was just correcting a typo in a filename) is unrelated.

So lets start here: Make sure you have all of the latest binaries and none of the old ones... This is not limited to only MIS/MIS2 but all of the binaries - please double check them.

After they are double checked, we should probably validate the binaries are all set to the proper user/group and chown -R everything in the Mystic directory structure to that user/group. Finally do a "fidopoll killbusy all" so we're starting with a clean slate with no residue (validate that with your find command).

Keep an eye on the access rights, particularly directory ownership of temp directories, and especially if you deleted mis and kept mis2 on your disk while you ran mis2. During mis2 development there were a couple of things that could cause it to start creating files and directories with the wrong access.

Once this is all done try going through everything manually, starting with running fidopoll the same way your event would execute it. Check for BSY files after it runs, or note obviously if it crashes or something. Since you say
you can reproduce this every time, it should be obvious where the problem occurs when you execute through the steps manually.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

* An ongoing debate between robert wolfe and Ryan Fantus rages on ...

Hm, interesting. I'll give mis a shot. I'm running 1.12a37, which
I upgraded from 1.12a36 (which was a fresh install). I missed the
bit about mis2 being deprecated :)

Sounds like the reply I was going to give :) So are we not to use
mis2 anymore?

MIS2 was deprecated as of v1.12 A36. Use MIS ONLY after installing A36 :) The updated MIS.Exe in A36 is a renamed version of MIS2.Exe and operates the same.


.- Keep the faith, --------------------------------------------------.
| |
| Ben aka cMech Web: http|ftp|binkp|telnet://cmech.dynip.com |
| Email: fido4cmech(at)lusfiber.net |
| Home page: http://cmech.dynip.com/homepage/ |
| | `-------- WildCat! BBS 24/7 +1-337-984-4794 any BAUD 8,N,1 -------'

... Zen football: A long pass out of the I formation.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

again. That said, I'm using mis2, with a36, as it includes an ssh server...is this unsupported?

Well you can do whatever you want :)

But I can't support a mix and match of old versions of Mystic that may or may not be compatible with each other, have known issues, etc. A36 doesn't even have a MIS2 so I don't know what you're actually using lol.

I get that you also need a working BBS too, so I understand why you're back to the old version. But I can't address or help or resolve anything if I don't have the person who has the problem around to help me. I can't send you a new binary with a fix if you're not at the current release level, etc.

DOSEMU was not complaining about security, in fact none of the
complaints were related to security or ownership. DOSEMU complained
about not being able to figure out character sets (cp437, auto, us, etc)

I'm not super familiar with DOSEMU but if the error is that it can't read its configuration to get the default character set, then I would think that could be very possibly be related to security.

Most earlier copies of test-release MIS2 (before it had all of the servers fully functional) had an issue where in some cases it wasn't dropping its root access after port binding...

If you happen to build and test your BBS with that server exclusively, and then switch to the "stable" version which doesn't have that issue, I think it would cause all sorts of random shit to go wrong.

As far as the BSY files, the FSXNET hub gets hammered and really tests this stuff hard. There are times when all 16 incoming BINKP nodes are active at once receiving mail while there is also outbound BINKP and echomail tossing all happening in harmony...

My point is that if it was a general issue like BSY files not getting deleted, then the entire network would halt within minutes of deploying the server. Thee would also be a LOT of people reporting the same issue, and so far its only you.

The only other commonality between being unable to delete a BSY file and a piece of software not reading its configuration values in my mind, would be something with security either on the admin side or the software side.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

I wasn't saying that to be flippant. A bog standard 112a36 64 bit linux package installed both mis and mis2, and I was using mis2 because it included ssh. I had no idea that it was unsupported. Standard mis looks like the old mystic server.

If you have some copy of A36 that has mis and mis2 then you don't have a real copy of A36. Not sure if you knew that beforehand or not, but the legit copy of A36 will only have the server and nothing else. No mis2, no old looking server. Just mis (the server formally known as mis2).

You can download the A36 release at mysticbbs.com/downloads if you need it.

I can try to repro, I guess. It may be a minimal cost for me to rent additional server space temporarily while we figure this out. I'll mull that over tonight and more than likely will just pull the trigger on getting another box.

Are you able to install another copy in a separate directory so you can do some testing with the new version? I'm not sure how your server works, but if its by space then a fresh Mystic only takes 3 megabytes. You could just use different ports if you wanted to run any of the servers.

If you can do a side install we could use the latest in-progress A37 from www.mysticbbs.com/downloads/prealpha, and we can work with that until we resolve things with DOSEMU, etc.

I could've sworn the fsx hubs were Windows machines, but I could be
wrong. Like I said, I'll try to repro, something got into a funky state and I'm not sure why. *shrug*

Yes the main hub is Windows but the mailer's logic and code doesn't change between operating system versions. The Linux version is probably more heavily used than the Windows version in general.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

I also notice my dos doors have stopped working. So, I decided to go for
a fresh install. Dos doors are still broken. Working on message nets shortly :(

Is DOSEMU complaining about security? Doors saying they cannot access files? If so, it could be that MIS2 was accidentally running as root for a long time, and now its not.

ge.mem is just a memory trace of GE.exe which is my SDL-based ANSI editor called Genesis Engine that has existed for like 15 years now unreleased. I
use it to edit Mystic's ANSI files or prototype UI stuff and what you see is just residue of that.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Ryan Fantus wrote to Paul Hayton <=-

Hm, interesting. I'll give mis a shot. I'm running 1.12a37, which I upgraded from 1.12a36 (which was a fresh install). I missed the bit
about mis2 being deprecated :)

Sounds like the reply I was going to give :) So are we not to use mis2 anymore?

... File not found. Should I fake it? (Y/N)
___ MultiMail/Linux v0.50

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Ben Ritchey wrote to Warp 4 <=-

Hm, interesting. I'll give mis a shot. I'm running 1.12a37, which
I upgraded from 1.12a36 (which was a fresh install). I missed the
bit about mis2 being deprecated :)

Sounds like the reply I was going to give :) So are we not to use
mis2 anymore?

MIS2 was deprecated as of v1.12 A36. Use MIS ONLY after installing A36
:) The updated MIS.Exe in A36 is a renamed version of MIS2.Exe and operates the same.

Now someone tells me, but it looks like there was no harm done.

... A bit like trying to stuff sausage casings with living animals.
___ MultiMail/Linux v0.50

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)