The current system is that temp directories are made in the root directory of Mystic (ie: C:\MYSTIC\TEMP1, C:\MYSTIC\TEMP2). I did it this way just because Renegade did it that way and it would be familiar, but secretly I think its sloppy and it bothers me.
What I would like to do is have it create a single TEMP (or maybe WORK) directory and then subdirectories off of that, so you only end up with one folder off the root Mystic directory. IE:
C:\MYSTIC\TEMP\1\
You can do what you want... My personal preference would be to keep it as-is, but as I said... it's your call.
Since it relates only to the number of "Nodes" being run as well as where Drop Files are placed for doors, most people don't run a ton of Nodes on their BBS. I've maxed mine out to 8, but Rarely ever get more than 2 people on at any given time so the structure is not messy for my preferences...
There is no real reason to change it other than to neaten up the
directory structure, so if people oppose it then its highly probable
that I won't do it.
In A46 I can thinking about changing the TEMP directory system and I wanted to mention it before I do it because it could affect a some
people who have doors setup using those paths hardcoded into their scripts, or maybe some custom MPL programs.
I would have to redo 8x node settings on 60x doorgames. My vote is no, simply because it would add work for me, but I'm indifferent otherwise.
I appreciate the feedback, this is exactly what I am looking for :)
What I would like to do is have it create a single TEMP (or maybe WORK) directory and then subdirectories off of that, so you only end up with
one folder off the root Mystic directory. IE:
I would have to redo 8x node settings on 60x doorgames. My vote is no, simply because it would add work for me, but I'm indifferent otherwise.
My vote, for whatever it is worth ... yes. Please do -- or perhaps save
it for a "2.0" major release. Also, can we do something about file base data in the /data directory? Maybe handle them similar to the way
message bases are done? That would tidy things up too.
I'm going to have to agree with ryan here, I have a shit load of dos door games running under dosemu with the node path mapped to the temp folder structure for door.sys files.
Sounds great, I think! Zi>
On my machine, I keep config files and as much as possible on a network share (except for the binaries). And I'd love to be able to point the "root" temp directory either to the network share or to a tmpfs file system, which would be really easy then.
There is a %P code that returns the path to the drop files that can eliminate much of the hardcode path stuff but I don't know how many
people actually use it.
What I wanted to do a while back was to have:
\MYSTIC\DATA All of the existing data files except msg/file bases \MYSTIC\DATA\FDB All of the file base data files
\MYSTIC\DATA\MDB All of the message base data files
I would have to redo 8x node settings on 60x doorgames. My vote is no simply because it would add work for me, but I'm indifferent otherwis
I am guessing you don't use %P for the path to the door file? ;)
There is a %P code that returns the path to the drop files that can eliminate much of the hardcode path stuff but I don't know how many people actually use it.
I do use it, the issue lies in all of the batch files that we use in dosemu, where a path needs to be lrdir's in dosemu. That is where all of the changes would need to happen. Can't use %P for that.
There is a %P code that returns the path to the drop files that can eliminate much of the hardcode path stuff but I don't know how many people actually use it.
I do use it, the issue lies in all of the batch files that we use in dosemu, where a path needs to be lrdir's in dosemu. That is where all of the changes would need to happen. Can't use %P for that.
\MYSTIC\DATA All of the existing data files except msg/file \MYSTIC\DATA\FDB All of the file base data files
\MYSTIC\DATA\MDB All of the message base data files
The current system is that temp directories are made in the root
directory of Mystic (ie: C:\MYSTIC\TEMP1, C:\MYSTIC\TEMP2). I did it
this way just because Renegade did it that way and it would be familiar, but secretly I think its sloppy and it bothers me.
What I would like to do is have it create a single TEMP (or maybe WORK) directory and then subdirectories off of that, so you only end up with
one folder off the root Mystic directory. IE:
C:\MYSTIC\TEMP\1\
C:\MYSTIC\TEMP\2\
On a different note, I for a while have been having a problem with
mutil replacing dupe files even if I have it set to true. I
changed in mystic cfg in file base settings on Upload Dupe to
Currrent and that didn't work so changed it to none. It.
curiously happens to those files named pasndlist.045 or
pasnlist.z45 and stndlist.z45 (the number changes with each
update. Log tells me it is a dupe as the only error.
I "Personally" would rather it stay the same as it is...
In A46 I can thinking about changing the TEMP directory system and I wanted to mention it before I do it because it could affect a some
I am guessing you don't use %P for the path to the door file? ;)
I am guessing you don't use %P for the path to the door file? ;)
A lot of older DOS stuff requires hard coded paths in the cfg files.
On my machine, I keep config files and as much as possible on a network share (except for the binaries). And I'd love to be able to point the "root" temp directory either to the network share or to a tmpfs file system, which would be really easy then.
path to the drop files in it. It was really annoying if you were
setting up like a 12 node BBS or something.
On 02-17-20 22:28, g00r00 wrote to All <=-
In A46 I can thinking about changing the TEMP directory system and I wanted to mention it before I do it because it could affect a some
people who have doors setup using those paths hardcoded into their scripts, or maybe some custom MPL programs.
On 02-18-20 19:37, alter ego wrote to g00r00 <=-
I think this is much better - that way, C:\MYSTIC\TEMP could be a mount
to a "temp" filesystem - which for Windows might night be C:. For unix,
it could be a ramdrive, etc.
For those running Mystic on a Pi, it definately makes sense that "temp"
is a ramdrive, not the SD card..
On 02-18-20 11:48, Embalmed wrote to g00r00 <=-
I have always operated under the impression the %P was only going to render on the first call out to the batch/shell script but I haven't tested this.
I too don't mind the proposed folder structure but would have 20-30 or
so doors that would all need reconfiguring. Some can be changed in the calling batch file, some require running the door games config utility, and some require editing a file like SRDOOR.1,SRDOOR.2 etc.
On 02-18-20 12:22, Al wrote to g00r00 <=-
\MYSTIC\DATA All of the existing data files except msg/file \MYSTIC\DATA\FDB All of the file base data files
\MYSTIC\DATA\MDB All of the message base data files
I like that idea for the FDB. I have wished the FDB was in it's own
place.
I think the message area config works great as it is. It's good in some cases to have a separate directory per net. It works well when you have like named areas (say, WINDOWS) in different nets.
I think a single directory could work if folks are sure to prefix filenames, something like fsx-fsx_gen. Perhaps a directory per net in
the base config of each net so all messages for that net use \MYSTIC\DATA\MDB\FSXNET, or something similar.
I also like the TEMP directory change you presented. Although it will
be some work for existing setups, it may be the right thing to do going forward.
Mystic is already quite simple to get online and maintain. It really shines in this area so I have to support anything that builds on that.
Maybe part of my problem is that I do load tests where I will have 25
node BBS that gets hit with 25 connections per second type of thing, so
I end up with TEMP0-25 plus all of the other TEMP directories used by other functions which end up being like 30 TEMP subdirectories.
I agree most BBSes aren't active enough to have those types of numbers, and even if they did its mostly just "cosmetic".
As far as drop files, there is a door MCI code that translates to the
path that is the location of the drop files. Any doors set up using
that (I think its %P) will not require any changes if the directories changed. Its only those who did not use %P and hard coded the node
number into batch files that would see an issue with configurations.
Yeah I know what you mean. I thin LORD worked that way where you had to physically go in and create a configuration for each node and hardcode a
If there were a temp dir config option and the subfolder naming scheme remained the same it could be done in a backwards compatible manner.
eg: /home/mystic/temp/temp1
For backwards compatibility just point it at the mystic directory itself and it should behave as it already does.
I am guessing you don't use %P for the path to the door file? ;)
pasnlist.z45 and stndlist.z45 (the number changes with each
update. Log tells me it is a dupe as the only error.
I don't have a solution but I am curious, do those tics have a line like "Replaces pasnlist.z45"?
Ttyl :-),
Al
| Sysop: | Eric Oulashin |
|---|---|
| Location: | Beaverton, Oregon, USA |
| Users: | 128 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 11:46:26 |
| Calls: | 1,549 |
| Files: | 2,153 |
| Messages: | 313,665 |