Mystic v1.12 A34 is released on www.mysticbbs.com
[---WHATSNEW---]
Could changes you made in this space be leading to issues in file hatch CRC problems I'm now seeing in the Mystic .TICs ?
Files sent from A34 at 1/100 have landed at 1/101 (running A33) and are being rejected with a 'Bad File CRC' error for each.
Could changes you made in this space be leading to issues in file hat CRC problems I'm now seeing in the Mystic .TICs ?
No its just that the CRC function is broken. Crap... Sorry. I'll have
to do some testing to get it fixed up and get an A35 out sooner than later.
In the meantime if anyone has suggestions for improving hatching please let me know. I know people want announcements which I hope to do soon.
I just have to research and refresh my memory on how those are usually handled in things like AllFix etc.
One idea I have is to be able to flag a file base as "automatically
hatch all new files" and then MUTIL will automatically hatch any new
files added to that file area when they are added.
This could be dangerous though if someone made a mistake and uploaded a ton of files, they could end up hatching a lot of files. I am not sure
if this is a feature that people would use?
I have a new mutil.rar at www.mysticbbs.com/downloads/mutil.rar
This is a Win32 version which may fix the CRC problem.
I have a new mutil.rar at www.mysticbbs.com/downloads/mutil.rar
This is a Win32 version which may fix the CRC problem.
Thanks, grabbed, it now testing with a test hatch of fsxNet infopack... will let you know.
Best, Paul
loud here... or something in the file index lister or just the file listing view for users with correct ACS to be able to tag files for hatching much like users tag them for bulk download....
Nope, sadly the same..
Okay thanks. Back to the drawing board. I'll setup a system here to
test with so I can get it right. I thought I saw the problem right away but I guess not.
I'll have another one available within the next day
This is something I was planning to do (its the reason hatch ACS is already there). I thought I'd have a (H)atch option right in the file lister, and anyone with the Hatch ACS can hatch files they select.
I think you're right about keeping hatching manual for now.
As far as announcements, should Mystic just track any files that are received by .TIC and then create an announcement of all files received since the last time an announcement was made? What should it do for hatched files?
Do systems ever announce files that aren't part of file echos? My
thoughts are that any files received via .TIC files OR hatched by the SysOp would be included in the announcement.
This isn't something I've ever done with Allfix or anything else, so I'm not clear on exactly how people typically use announcements.
Yep seems reasonable to me, but do ponder the points I raised about HUB operators wanting to moderate hatched flows from nodes if so desired.
Else it could be an uncontrolled free for all which worries me a bit. Perhaps I'm being to anal about that?
Something that could show files hatched by file base group so all the fsxNet then all Fidonet etc.
Well, the hatching from the file list should generally be a sysop-only function. I would probably default new areas to set that to "s255" in
the future.
The ACS is there because (for example), you may want to give just *me* access to hatch in the Mystic file areas from your BBS - so I could call in and upload new releases and hatch them immediately... Things like that.
Remember we can specify specific users within ACS strings... so this
will allow us to assign certain people or groups of people who can moderate and hatch within individual file bases. Or we can just keep it s255 and only the Sysop does it.
Yep, we absolutely want some way to do this. I am curious as to how Allfix (or other utilities) define/separate this information...
Of the top of my head: Maybe we do it by echomail address, since each
base is assigned to an echomail address specific to a network:
announce.exe <echomail domain> <base IDs to post>
announce fsxnet 1,64,23,2
^^ posts the announcement for all new files that came into any file base configured to the fsxnet domain to message base #1, 64, 23, and 2. Those announced files are then removed from the "announcement" database.
Yep all understood but... there's nothing in place as far as I can tell
to enable any file hatching moderation (perhaps the wrong word but I
think you get the gist of what I am trying to say) of files being sent
out to all nodes in a network by anyone with a connection to a HUB file base.
Sounds good, I think also something that can track overall file hatching stats over a period of time based on those announce.exe sessions. So if you want to report on total numbers of files hatched by echomail domain
by file echo for the last 30,60,90 days you can get it. It would mean
Yep all understood but... there's nothing in place as far as I can te to enable any file hatching moderation (perhaps the wrong word but I think you get the gist of what I am trying to say) of files being sen out to all nodes in a network by anyone with a connection to a HUB fi base.
Do you mean in a case where another BBS (say mine for example) hatches a file in FSX_INFO and it gets sent to you, then your BBS will toss it all of the downlinks? I can see how that is a problem. What does Allfix do to prevent this?
That's one way of doing it and I think it could work. As mentioned above it seems like Allfix is more granular in it's permitted control over
nodes and file groups to allow send and/or receive at those levels too.
I went ahead and added the "File Hub" flag which means that it will not toss any incoming files to that area at all from any downlinks, but I
can see how doing that on a per-node basis might be good too.
I want to see if I can make it as easy to manage as possible, so we
don't have to jump to a bunch of different places in order to set things up.
I do like the idea of groups. I'll have to think about how we can
enhance both echomail and filemail to include some sort of group system without making it too convoluted.
So do you think there should be an [AutoHatch] stanza in MUTIL? Or
should it be more accessible by command line like "mis hatch FSX_INFO fsxpack.zip replace"
I am a little hesitant on this one just because of someone accidentally wildcarding and hatching 1000 files without realizing it, particularly if we're going to put it into MUTIL.
rather sit on hold until the node polls... some setting like filebox autohold if file size > x Kb
I've actually added this already its just not showing in the
configuration because I've never tested it. I am going to enable this
now and it will be in the next build but probably still untested by me.
Also the next build has a minor change in the function that receives data during BINKP transfers. It seems to be working fine for me on my BBS
but I just wanted to mention it so you are in the loop. Obviously binkp actually working is a big deal for you. :)
I'll go ahead and make a new build now for you.
a way to ensure those systems did crash any/all messages/files if the echonode was so set to do so.
It should allow you to limit per echomail node based as granular as 1 kilobyte up to about 10 gigabytes.
I think both but in order of effort I would do MUTIL first as most are familiar with it. But I know you want to roll things into MIS so it's worth doing so down the track.
rather sit on hold until the node polls... some setting like fil autohold if file size > x Kb
I've actually added this already its just not showing in the configuration because I've never tested it. I am going to enable thi now and it will be in the next build but probably still untested by m
Heh good to know I'm not the only one pondering this. :)
It should allow you to limit per echomail node based as granular as 1 kilobyte up to about 10 gigabytes.
Then that's sounding ideal - thanks!
So do you think there should be an [AutoHatch] stanza in MUTIL? Or should it be more accessible by command line like "mis hatch FSX_INFO fsxpack.zip replace"
I think both but in order of effort I would do MUTIL first as most are familiar with it. But I know you want to roll things into MIS so it's
Do we want Mystic to hatch without the requirement of having to have a file in the base? Should it upload it to the base if it doesn't exist
and then hatch, or should it just require that it already exists before
it will hatch?
My thoughts are that if you're going to hatch a file it should require
it to actually be in the file listing for that file echo otherwise you
can hatch files out that don't even exists in the hub's file base.
[AutoHatch]
; List of files to hatch automatically when executed
; Format: Area ID or echotag, filename, replaces filename (optional)
; All fields are separated by a pipe character |
file = fsx_info | fsxinfo.zip | fsxinfo.zip
file = 10 | fsxnode.zip | fsxnode.zip
And to be honest that's a pain to do for one or more files, which is why at the moment when I hatch things I use an external TIC generation tool
to create something for Mystic to ingest that handles both import into
the file base and tossing and hatching to connected nodes all in one hit... much easier.
So I'd like to ask for an option one also- Mystic to upload to the base and hatch. But this should be something separate from what we're brainstorming as a AutoHatch function in MUTIL.
I'm wondering perhaps it can be something added to the MassUpload
function so there's a hatch switch?
My thoughts are that if you're going to hatch a file it should require
it to actually be in the file listing for that file echo otherwise you
can hatch files out that don't even exists in the hub's file base.
I opted to follow the process of finding a new file, dropping it in to fsx_utls file directory on the local HDD, logging into the HUB, and running the mass upload option from the file menu for the fsx_utils base.
snip<=-
snip<=-
The TIC workaround you're already doing is very clever, and I am
wondering if maybe Mystic shouldn't just do the same thing? So if you hatch from command line all it'd really do is copy it to your inbound
and create a .TIC for it, then MUTIL will import it to you BBS and
toss it to the downlinks.
Wouldn't it be easier to just use the mutil.ini stanza [MassUpload]?
Perhaps if something could be added to that stanza, which allows imported files to be auto hatched...
This is my process for hatching a bunch of brand new files now:
rather sit on hold until the node polls... some setting lik autohold if file size > x Kb
I've actually added this already its just not showing in the configuration because I've never tested it. I am going to enabl now and it will be in the next build but probably still untested
Heh good to know I'm not the only one pondering this. :)
Nope this was all your idea! You had mentioned it to me some time ago
and I thought it was a great idea, so you get all the credit! :)
This is my process for hatching a bunch of brand new files now:
highlighted. Press E to edit, then select hatch press ] to go to the
next file, then select hatch, ] hatch ] hatch. It should only take
about a minute or two to hatch those files.
From a command line you'll still have to type:
mutil hatch fsx_info c:\mystic\myfiles\file1.zip replace file1.zip
mutil hatch fsx_info c:\mystic\myfiles\file2.zip replace file2.zip
I am not disagreeing that there should be a better way, just thinking
out loud I guess about whether or not its really that much faster.
The TIC workaround you're already doing is very clever, and I am
wondering if maybe Mystic shouldn't just do the same thing? So if you hatch from command line all it'd really do is copy it to your inbound
and create a .TIC for it, then MUTIL will import it to you BBS and toss
it to the downlinks.
So I'd like to ask for an option one also- Mystic to upload to the ba and hatch. But this should be something separate from what we're brainstorming as a AutoHatch function in MUTIL.
Okay so we could have AutoHatch in MUTIL only work if the file exists,
but then a separate command line option that would copy it into the file base, upload it, and then hatch it (or if the file exists, it'd just update the existing record and still hatch it). Sounds reasonable to me!
I'm wondering perhaps it can be something added to the MassUpload function so there's a hatch switch?
Maybe it could even be a flag on a file base "Auto hatch" which automatically hatches any new files that are mass uploaded into that
base. But it would not hatch files that are uploaded into the base by a BBS user.
I do worry a little bit that someone could accidentally toggle the flag
ON and end up hatching a bunch of files out somewhere. Even if it seems far fetched people really do seem to sometimes find ways to do some far fetched things :)
Well I think now we have even more possible options on the table with
all of this discussion haha! I am not sure which approach to take. Out of all of these ideas which do you think would be the most useful combination of options for you?
Works for me, so long as Mystic can tell it's a valid TIC etc. as at present to do this trick I have to create an echonode record for the system sending in the TIC.
I can't recall with the MUTIL re-hatch stanza if you were looking to
make a provision for an external TXT file to be able to be stipulated as the source list of files to be re-hatched? But if you could include it
as an option that would be helpful too.
I am leaning more towards having it do the import and hatch itself, and then the next time the file tosser runs it will toss it. So it'd be a "real" hatch not a kludge using a .TIC.
I can't recall with the MUTIL re-hatch stanza if you were looking to make a provision for an external TXT file to be able to be stipulated the source list of files to be re-hatched? But if you could include i as an option that would be helpful too.
You did mention this but to be honest I probably wasn't going to do it.
Do you already have a list of files somewhere that you don't want to put into the AutoHatch stanza? I just want to get a feel of how you'd use
it and the benefit of it being in an external file instead of having it defined in the stanza itself. I was planning just to do it like:
| Sysop: | sneaky |
|---|---|
| Location: | Ashburton,NZ |
| Users: | 2 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 96:12:06 |
| Calls: | 2,123 |
| Calls today: | 4 |
| Files: | 11,149 |
| D/L today: |
51 files (22,102K bytes) |
| Messages: | 950,695 |