Your AREAFIX request has been processed

Command: %LINKED
Result: List of all linked areas:
FSX_GEN
FSX_MYS
FSX_BOT
FSX_CRY
FSX_BBS

Command: %UNLINKED
Result: List of all unlinked areas:

I think I saw a thread about this but I'm too sleepy to read through right
now and thought I would also post this..

Where's the file echos?

--- Mystic BBS v1.12 A35 (Linux/64)
* Origin: tEMPLEoFsYRINX.info : for the do-it-yourselfer (21:1/167)

On 12/01/17, syrinxcultist said the following...

Your AREAFIX request has been processed

Command: %LINKED
Result: List of all linked areas:
FSX_GEN
FSX_MYS
FSX_BOT
FSX_CRY
FSX_BBS

Command: %UNLINKED
Result: List of all unlinked areas:

I think I saw a thread about this but I'm too sleepy to read through
right now and thought I would also post this..

Where's the file echos?

Have they been created? For mystic the standard menu used M for messages and they show up there, an I gets an Indexed List of all areas if things are working and setup right. LINKED means you'll get things going forward, to get the older messages send %RESCAN to AREAFIX, it will pull in all linked areas. In truth they 'live' in /mystic/msgs but that's no way to really read them, does show you their created though.

--- Mystic BBS v1.12 A36 2017/11/30 (Linux/64)
* Origin: Mystic AlphaTest bcw142.zapto.org:2323 (21:1/145.2)

On 12/01/17, syrinxcultist said the following...

Your AREAFIX request has been processed

Command: %LINKED
Result: List of all linked areas:
FSX_GEN
FSX_MYS
FSX_BOT
FSX_CRY
FSX_BBS

Command: %UNLINKED
Result: List of all unlinked areas:

I think I saw a thread about this but I'm too sleepy to read through right now and thought I would also post this..

Where's the file echos?

Have they been created? For mystic the standard menu used M for messages and they show up there, an I gets an Indexed List of all areas if things are working and setup right. LINKED means you'll get things going
forward, to get the older messages send %RESCAN to AREAFIX, it will pull in all linked areas. In truth they 'live' in /mystic/msgs but that's no way to really read them, does show you their created though.

I tried FILEFIX and it shows all file echos linked. It's not creating the
file bases... I'll try %RESCAN =/

--- Mystic BBS v1.12 A35 (Linux/64)
* Origin: tEMPLEoFsYRINX.info : for the do-it-yourselfer (21:1/167)

I think I saw a thread about this but I'm too sleepy to read through
right now and thought I would also post this..

Where's the file echos?

Areafix is for message bases, Filefix is for file bases.

--- Mystic BBS v1.12 A36 2017/11/30 (Windows/64)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

I tried FILEFIX and it shows all file echos linked. It's not creating
the file bases... I'll try %RESCAN =/

It won't create anything until you actually get a file to put in the base.

You also have to enable auto-create I think if you haven't.

--- Mystic BBS v1.12 A36 2017/12/01 (Windows/64)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 12/01/17, g00r00 pondered and said...

Areafix is for message bases, Filefix is for file bases.

Kinda like daytime is for work, nightime is for BBsing and Mystic :)

--- Mystic BBS v1.12 A36 2017/11/26 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

Areafix is for message bases, Filefix is for file bases.

hah, ya... still no lucky tho =/

--- Mystic BBS v1.12 A35 (Linux/64)
* Origin: tEMPLEoFsYRINX.info : for the do-it-yourselfer (21:1/167)

I tried FILEFIX and it shows all file echos linked. It's not creatin the file bases... I'll try %RESCAN =/

It won't create anything until you actually get a file to put in the
base.

You also have to enable auto-create I think if you haven't.

how do i get the hub to send older files?

--- Mystic BBS v1.12 A35 (Linux/64)
* Origin: tEMPLEoFsYRINX.info : for the do-it-yourselfer (21:1/167)

On 12/02/17, Avon said the following...

On 12/01/17, g00r00 pondered and said...

Areafix is for message bases, Filefix is for file bases.

Kinda like daytime is for work, nightime is for BBsing and Mystic :)

lol! i just quit my job... all time if for the later

--- Mystic BBS v1.12 A35 (Linux/64)
* Origin: tEMPLEoFsYRINX.info : for the do-it-yourselfer (21:1/167)

Hello Avon,

On 12/01/17, g00r00 pondered and said...

Areafix is for message bases, Filefix is for file bases.

Kinda like daytime is for work, nightime is for BBsing and Mystic :)

When ya get to be a certain age it all becomes one big blur. Sometimes I am working on this stuff at 2 in the afternoon and sometimes at 2 in the morning.

Jeff

--- BBBS/Li6 v4.10 Toy-3
* Origin: FsxNet: The Ouija Board - bbs.ouijabrd.net (21:1/128)

Hello syrinxcultist,

On 12/01/17, syrinxcultist said the following...

I tried FILEFIX and it shows all file echos linked. It's not creating the file bases... I'll try %RESCAN =/

One option would be to import a FSX_FILE.NA file. Importing the .NA file will create the Mystic file areas. Once created it would be wise to check the file area settings to make sure they are as you desire.

Imported or auto-created file areas will be empty until files start to come in or you manually upload them to the file areas.

I imported the existing Fsxnet file areas and have Mystic set to auto-create any new file areas should any files for unknown areas arrive.


Jeff

--- BBBS/Li6 v4.10 Toy-3
* Origin: FsxNet: The Ouija Board - bbs.ouijabrd.net (21:1/128)

On 12/01/17, syrinxcultist said the following...

I tried FILEFIX and it shows all file echos linked. It's not cr the file bases... I'll try %RESCAN =/

It won't create anything until you actually get a file to put in the base.

You also have to enable auto-create I think if you haven't.

how do i get the hub to send older files?

You don't, only the hub can send files at present. The main consideration is that files are generally much larger bases than messages (which are often zipped). To keep from overloading the hub there is no %RESCAN for files.
That's the way it is for mystic, Avon can send stuff and has every so often sent a file base out rather than just new files. Perhaps if %RESCAN was
limited in size (thus time) in some way so it only sent so much at a time and spaced it out a %RESCAN could work, but that makes it much more complicated then message bases which are generally much smaller.
The way to do it is to go to the hub and download the files a few at a time. Another way is ftp if it's up. Create the empty file base, fsx_info as an example. CD in to it, then ftp to the hub and download all the files using
ftp to that file base. Then you need to 'Upload' them to the base by entering files, that file base and doing the sysop /U command to 'Mass Upload' the files. Then you can do L for list and should see all the files there now. It will import the file_id.diz files and use them for descriptions automatically.

--- Mystic BBS v1.12 A36 2017/12/01 (Linux/64)
* Origin: Mystic AlphaTest bcw142.zapto.org:2323 (21:1/145.2)

new files. Perhaps if %RESCAN was limited in size (thus time) in some
way so it only sent so much at a time and spaced it out a %RESCAN could work, but that makes it much more complicated then message bases which

I am open to discussion on how we can make this work with everyone here. We could maybe do a sized-limited RESCAN option at some point?

--- Mystic BBS v1.12 A36 2017/12/01 (Windows/64)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 12/02/17, g00r00 pondered and said...

new files. Perhaps if %RESCAN was limited in size (thus time) in some way so it only sent so much at a time and spaced it out a %RESCAN cou work, but that makes it much more complicated then message bases whic

I am open to discussion on how we can make this work with everyone here. We could maybe do a sized-limited RESCAN option at some point?

Interesting observation. Today I hatched out three larger ANSI art packs.

You will have already seen the impact on BinkP server - the HUB got to 16 connections running simultaneously pulling down the files while Fidopoll started at xx and ended at 12:11pm after polling 12 nodes set to CRASH
traffic.

[snip]

Dec 03 07:26:57 Queued 6 files (89832972 bytes) to 21:1/102
Dec 03 07:26:57 Polling BINKP node 21:1/102 by IPV4
Dec 03 07:26:57 Connecting to error404bbs.ddns.net
Dec 03 07:26:57 Connected

[snip]

4.5 hours later....

[snip]

Dec 03 12:11:04 Queued 0 files (0 bytes) to 21:1/199
Dec 03 12:11:04 Scanning 21:3/100
Dec 03 12:11:04 Queued 0 files (0 bytes) to 21:3/100
Dec 03 12:11:04 Scanning 21:1/200
Dec 03 12:11:04 Queued 0 files (0 bytes) to 21:1/200
Dec 03 12:11:04 Polled 12 nodes

[snip]

Once Fidopoll had ended there were approx. 15 packets waiting to be processed that had banked up in echomail\in during this time. Not ideal.

Some ideas.

I tend to think it would be good if a HUB could set the following

Max file size a node can be Fidopolled with, so if the file is larger than X
it should sit in the filebox waiting for the node to poll the BinkP server.

I know fileboxes don't work that way but that's the idea I have :)

Perhaps also a way of setting something on a file base by file base basis...
so that either a HUB can force files hatched from that base above X size to
be held for nodes to poll and collect, or if the setting is set to None, then all files hatched from that filebase must be polled for an won't ever be sent as CRASH traffic by Fidopoll.

I guess you argue the same for message bases but I really think this is only going to be an issue for file bases.

It would be good (soon) to introduce the extra ACS style settings for a HUB operation to allow better control over nodes linking/delinking /rescan etc.
for echo and file bases.

I know I am forever having to delink the new sysop node /999 from all the
file echos as new folks are flexing their filefix muscles.. :)

Best, Paul

--- Mystic BBS v1.12 A36 2017/12/01 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

Rescan is a good idea.

On 07:32 02/12 , g00r00 wrote:

new files. Perhaps if %RESCAN was limited in size (thus time) in some
way so it only sent so much at a time and spaced it out a %RESCAN could work, but that makes it much more complicated then message bases which

I am open to discussion on how we can make this work with everyone here. We >could maybe do a sized-limited RESCAN option at some point?

--- Mystic BBS v1.12 A36 2017/12/01 (Windows/64)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

--
yrNews Usenet Reader for iOS
http://appstore.com/yrNewsUsenetReader

--- Mystic BBS/NNTP v1.12 A36 2017/11/30 (Linux/64)
* Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)

You will have already seen the impact on BinkP server - the HUB got to 16 connections running simultaneously pulling down the files while Fidopoll started at xx and ended at 12:11pm after polling 12 nodes set to CRASH traffic.

Dec 03 07:26:57 Queued 6 files (89832972 bytes) to 21:1/102

Yep and that is only a handful of files! This is exactly why I haven't yet allowed this move, despite many people asking for it:

To: Filefix
Subj: OMGGIMMEFILES
+ALL
%RESCAN

Once Fidopoll had ended there were approx. 15 packets waiting to be processed that had banked up in echomail\in during this time. Not ideal.

I agree it would be nice to not have that bottleneck. The good news is I do think there are several things we can do and I think a combination of ideas
is the best way.

Max file size a node can be Fidopolled with, so if the file is larger
than X it should sit in the filebox waiting for the node to poll the
BinkP server.
I know fileboxes don't work that way but that's the idea I have :)

So am I correct in thinking these files would already be sitting in each node's filebox? If that is the scenario we're talking about then adding a size threshold for outbound polling I think would be pretty painless for me to do.

As I know you are more aware than anyone, Mystic's BINKP seems to be holding up quite well under extreme load in these latest alphas, so another option would be to open up FIDOPOLL so that it will open X amount of connections at once instead of crashing each node sequentially.

I've been considering merging FIDOPOLL into MIS and then we'd just see MIS message window telling us "Connecting to X, sending X, receiving X" showing up when its sending stuff out. We would have a configurable number of simultaneous outbound connections instead of crashing sequentially.

The combination of the two is what I think would be ideal, but...

The third idea because at the time of a filebox crash, the BINKP protocol doesn't know much about the origin of a file so having an association between the file and the file base it came from would be needed for FIDOPOLL to pull that configuration information. It wouldn't be impossible, but I don't know the investment of time would be worth it in comparison to the other two ideas above.

I know I am forever having to delink the new sysop node /999 from all the file echos as new folks are flexing their filefix muscles.. :)

Shame on them! Hopefully I'll be able to stop that soon.

I don't know if you've seen the most recent configuration changes yet, but there is now a "Networking" tab. That was "step 1" of my plan for implementing the echomail security/group system. Hopefully soon I'll be able to get something put together.

--- Mystic BBS v1.12 A37 2017/12/09 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

Rescan is a good idea.

I wish it were that simple but it has to be managed carefully.

Avon's just recently said hatching 3 files took 5 hours to send. Now turn that 3 into 3000 and you have 15,000 hours to send where you cannot get your echomail because nodes are doing a file echo rescan.

15,000 hours is nearly 2 years. I am going to assume that most nodes would not like to wait nearly 2 years between echomail packets being sent to them. :)

Obviously my example is crazy extreme because not all nodes will do a rescan of file bases all at once, but I've already had several people say "Hey I want to do +ALL %RESCAN can you add that in!" I think a couple of people just this week did it.

If a handful of people did that at once I don't think its unheard of that we could get stuck in a scenario where it would take a month to send the queue, causing echomail to get stuck for a month.

--- Mystic BBS v1.12 A37 2017/12/09 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 12/09/17, g00r00 said the following...

Obviously my example is crazy extreme because not all nodes will do a rescan of file bases all at once, but I've already had several people
say "Hey I want to do +ALL %RESCAN can you add that in!" I think a
couple of people just this week did it.

There are quite a few reasons no other software ever implemented this feature for filefix. Rescanning messages from areafix is one thing.. but who knows
how many files are in a file area, and who knows the size of all of them.
We're not trying to give out leech access, there are other protocols for that (FTP and HTTP comes to mind).

Regards,
Nick

--- Mystic BBS v1.12 A37 2017/12/09 (Linux/64)
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

On 12/09/17, Accession said the following...

Obviously my example is crazy extreme because not all nodes will do a rescan of file bases all at once, but I've already had several people say "Hey I want to do +ALL %RESCAN can you add that in!" I think a couple of people just this week did it.

There are quite a few reasons no other software ever implemented this feature for filefix. Rescanning messages from areafix is one thing.. but

I would have to agree with you on that.

who knows how many files are in a file area, and who knows the size of
all of them. We're not trying to give out leech access, there are other protocols for that (FTP and HTTP comes to mind).

Exactly. I'm connected to one Fido file echo uplink, who has files from many years ago still on his system. I'm sure if someone did a rescan of his
system, they would be downloading for many hours.

Also, you can add to that list of protocols, the person can get the files the old-fashioned way. "Call" the BBS and download them. ;)


---

Black Panther
a.k.a. Dan Richter
Sysop - Castle Rock BBS (RCS)
The sparrows are flying again....

--- Mystic BBS v1.12 A37 2017/12/09 (Linux/64)
* Origin: Castle Rock BBS - castlerockbbs.com (21:1/186)

On 12/09/17, g00r00 pondered and said...

Yep and that is only a handful of files! This is exactly why I haven't yet allowed this move, despite many people asking for it:

To: Filefix
Subj: OMGGIMMEFILES
+ALL
%RESCAN

It should be noted that in my reported example it was just three files, but each file was 31, 22, and 32 megabytes each... so pretty big by BBS file transfer standards and it was I think the fact they were so much larger (compared to a let's say a 2 megabyte copy of a Mystic installer) and that I suspect the binkp protocol might be not a very fast protocol in terms of file transfers?? that caused the issue when you add 52 nodes all either polling in for those x 3 larger files and/or fidopoll trying to CRASH them out to them sequentially.. and that sequential thing is a pain in the rear when you start getting up in node count.

I agree it would be nice to not have that bottleneck. The good news is
I do think there are several things we can do and I think a combination
of ideas is the best way.

:)

Max file size a node can be Fidopolled with, so if the file is larger than X it should sit in the filebox waiting for the node to poll the BinkP server.
I know fileboxes don't work that way but that's the idea I have :)

So am I correct in thinking these files would already be sitting in each node's filebox? If that is the scenario we're talking about then adding
a size threshold for outbound polling I think would be pretty painless
for me to do.

Yes you are correct they are tossed out to fileboxes as part of a hatching exercise then fidopoll send is usually run thereafter... nodes start to poll
in a fidopoll starts working very hard trying to push stuff out, one node at
a time..

As I know you are more aware than anyone, Mystic's BINKP seems to be holding up quite well under extreme load in these latest alphas, so another option would be to open up FIDOPOLL so that it will open X
amount of connections at once instead of crashing each node sequentially.

I had been thinking of this also and ... hang a tic...

[time passes]

there it is... just looking at my wishlist notes from May this year

[snip]

***

The ability for fidopoll to allow for more than one connection
with a Binkp server when it polls so when a system polls another
(or th fsxNet HUB) and has multiple files to send/pick up it can
connect on several Binkp ports and pull down files etc. faster
vs. sitting on one port and tieing it up for a long time as files
are transferred.

***

[snip]

So yep, I was pondering this some time ago.

I've been considering merging FIDOPOLL into MIS and then we'd just see
MIS message window telling us "Connecting to X, sending X, receiving X" showing up when its sending stuff out. We would have a configurable number of simultaneous outbound connections instead of crashing sequentially.

Perhaps as a starter can you not just enable more concurrent outbound connections from the standalone fidopoll? The one thing I really like about having fidopoll standalone at the moment is that I can clearly see what is happening when it's running. My only worry about merging with MIS (and I can well see why you would want to) is retaining that ability to just look at outbound realtime polling activity without it getting lost in the MIS message window also working to display incoming info, events info etc..

If you do opt to go with merging to MIS can you add some more toggles so a sysop can filter the real time output on the fly?

The third idea because at the time of a filebox crash, the BINKP protocol doesn't know much about the origin of a file so having an association between the file and the file base it came from would be needed for FIDOPOLL to pull that configuration information. It wouldn't be impossible, but I don't know the investment of time would be worth it in comparison to the other two ideas above.

I'm not sure I really follow this one to be honest (but now it's late here
and once again my brain is fried - most of the day I have been thinking
Mystic stuff and juggling weekend family commitments) so if the concurrent sessions for fidopoll can be enabled I'd say go for this first if it's easier.

file echos as new folks are flexing their filefix muscles.. :)

Shame on them! Hopefully I'll be able to stop that soon.

ta!

I don't know if you've seen the most recent configuration changes yet,
but there is now a "Networking" tab. That was "step 1" of my plan for implementing the echomail security/group system. Hopefully soon I'll be able to get something put together.

I have just updated (see my tear line) and am about to poke about the new UI. It's a good idea on your part to group these items in the most logical way
etc. and equally good to allow space for growth :)

..and yes please, and thanks for any time you can put in to the echomail/file security/group system... once that is sorted and bedded in I will be looking
to retire BinkD and FastEcho from my Fido HUB and use Mystic to handle that..
I am also keen to have some degree of HUB control over the ability of nodes
to connect to echos/file bases unchecked.. aka the /999 scenario discussed already :)

Best, Paul

--- Mystic BBS v1.12 A37 2017/12/09 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

Hello g00r00,

Rescan is a good idea.

I wish it were that simple but it has to be managed carefully.
Avon's just recently said hatching 3 files took 5 hours to send. Now turn that 3 into 3000 and you have 15,000 hours to send where you cannot get your echomail because nodes are doing a file echo rescan.
15,000 hours is nearly 2 years.

I think that the capability of allowing a rescan of echomail is all well and good. If managed correctly. But as has been pointed out the effect on the sending system could easily be overwhelming. There are a number of alternative ways to acquire files IF they are deemed that important.

I recently watched as a 80 meg file came in from a Fido file echo. I can only imagine the load on the uplink's system as her system tried to send the file out to all her downlinks. And that was just a single file. Imagine a rescan of that file area.


Jeff

--- BBBS/Li6 v4.10 Toy-3
* Origin: FsxNet: The Ouija Board - bbs.ouijabrd.net (21:1/128)

On 12/09/17, Black Panther said the following...

Exactly. I'm connected to one Fido file echo uplink, who has files from many years ago still on his system. I'm sure if someone did a rescan of his system, they would be downloading for many hours.

Do they also have those files available for download via the BBS and/or FTP/HTTP?

Also, you can add to that list of protocols, the person can get the
files the old-fashioned way. "Call" the BBS and download them. ;)

Holy crap. Is that even a thing these days? ;)

Jokes aside, I guarantee you that's why there was never a filefix rescan capability. In these smaller networks it may be okay, but once you get 100+ files in an echo, the rescan will not go well. Limiting the amount of downloads, sure.. it's possible, but.. wasted effort, in my opinion. If the
hub also caters their file areas via another method, and you really really really need all those files, get them that way.

Who knows. I may be becoming an old-timer that doesn't know anything anymore. So, your miles may vary. ;)

Regards,
Nick

--- Mystic BBS v1.12 A37 2017/12/09 (Linux/64)
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

On 12/10/17, Avon said the following...

It should be noted that in my reported example it was just three files, but each file was 31, 22, and 32 megabytes each... so pretty big by BBS file transfer standards and it was I think the fact they were so much larger (compared to a let's say a 2 megabyte copy of a Mystic installer) and that I suspect the binkp protocol might be not a very fast protocol
in terms of file transfers?? that caused the issue when you add 52 nodes all either polling in for those x 3 larger files and/or fidopoll trying
to CRASH them out to them sequentially.. and that sequential thing is a pain in the rear when you start getting up in node count.

Which is another great reason for shitcanning the RESCAN option for filefix. Sorry to say kids, but this is a bad idea. ;)

Regards,
Nick

--- Mystic BBS v1.12 A37 2017/12/09 (Linux/64)
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

On 12/10/17, Accession said the following...

Exactly. I'm connected to one Fido file echo uplink, who has files fr many years ago still on his system. I'm sure if someone did a rescan his system, they would be downloading for many hours.

Do they also have those files available for download via the BBS and/or FTP/HTTP?

They are available via all methods. FTP/HTTP and via his BBS.

Also, you can add to that list of protocols, the person can get the files the old-fashioned way. "Call" the BBS and download them. ;)

Holy crap. Is that even a thing these days? ;)

Not as much as it was waaaaay back when. :)

Jokes aside, I guarantee you that's why there was never a filefix rescan capability. In these smaller networks it may be okay, but once you get 100+ files in an echo, the rescan will not go well. Limiting the amount
of downloads, sure.. it's possible, but.. wasted effort, in my opinion.
If the hub also caters their file areas via another method, and you
really really really need all those files, get them that way.

I agree. I don't think it would be a good idea to implement a filefix rescan. Just looking at what happened to Paul's system when he hatched out 3 larger files. It took hours for everyone to actually get those.

Who knows. I may be becoming an old-timer that doesn't know anything anymore. So, your miles may vary. ;)

I think we all are. ;) They say your only as old as you feel. If that's the case, I'm about 120 today...


---

Black Panther
a.k.a. Dan Richter
Sysop - Castle Rock BBS (RCS)
The sparrows are flying again....

--- Mystic BBS v1.12 A37 2017/12/09 (Linux/64)
* Origin: Castle Rock BBS - castlerockbbs.com (21:1/186)

If you do opt to go with merging to MIS can you add some more toggles so
a sysop can filter the real time output on the fly?

I do have filtering in the messages window on the list of things to experiment with. Along with the idea to tail any of the logs in its own tab, so you could just tail fidopoll.log in a tab of its own.

I was intending to allow it to still be executed from the command line as
well. You'd just type "MIS FIDOPOLL" or "MIS FIDO" instead of just FIDOPOLL, ie:

mis fido forced

--- Mystic BBS v1.12 A37 2017/12/10 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

Jokes aside, I guarantee you that's why there was never a filefix rescan capability. In these smaller networks it may be okay, but once you get 100+ files in an echo, the rescan will not go well. Limiting the amount
of downloads, sure.. it's possible, but.. wasted effort, in my opinion.
If the hub also caters their file areas via another method, and you
really really really need all those files, get them that way.

Who knows. I may be becoming an old-timer that doesn't know anything anymore. So, your miles may vary. ;)

Regards,
Nick

_________________________________________
< Google, download all files at Agency ;) >
-----------------------------------------
\ |15
___###
/oo\ ||||||||
\ / \|/
/""\ I
()| |(I) _________________
\ / I < By your command >
/""""\ I _/-----------------
| |I (_)
| |I
\____/ I


I suspect that would take a lot of setup to really work.

--- Mystic BBS v1.12 A37 2017/12/09 (Linux/64)
* Origin: Workpoint (21:1/145.3)