Any one know how to extend the limit for reporting files found on
system as mine seems to be set a bit on the low side at 50.
Just cannot find it.
Found it and it in mbfido/filefind.c
There are four settings :
----
/*
* The next constants are to prevent overflowing the echomail areas
* with huge replies. MAX_DESC_LINES limits the number of file description * lines, 5 should be enough. The other two are the
maximum files to report * if in the same area or different area. *
For netmail replies there is a different limit. */ #define
MAX_DESC_LINES 5 #define MAX_FILES_SAMEBOARD 25 #define MAX_FILES_OTHERBOARD 50 #define MAX_FILES_NETMAIL 100
----
Andrew is there any way we can change these as a param for configure
or better still within the system set up params ?
Hello Vince!
24 Oct 17 21:43, you wrote to all:
Found it and it in mbfido/filefind.c
There are four settings :
----
/*
* The next constants are to prevent overflowing the echomail
areas
* with huge replies. MAX_DESC_LINES limits the number of file
description * lines, 5 should be enough. The other two are the
maximum files to report * if in the same area or different area.
* For netmail replies there is a different limit. */ #define
MAX_DESC_LINES 5 #define MAX_FILES_SAMEBOARD 25
#define MAX_FILES_OTHERBOARD 50 #define MAX_FILES_NETMAIL
100
----
Andrew is there any way we can change these as a param for
configure or better still within the system set up params ?
We can probably do something about that without too much trouble. As
with anything, sysops will need to use common sense in setting limits
to prevent gigantic echomail messages.
In the future, I can look at possibly splitting large replies into
multiple messages.
In the future, I can look at possibly splitting large replies into
multiple messages.
In mbse there is a 60/64k message limit does this still apply in fido
land these days with internet comms used for most if not all sysops ?
On 2017 Oct 25 14:36:30, you wrote to Andrew Leary:
In the future, I can look at possibly splitting large replies
into multiple messages.
In mbse there is a 60/64k message limit does this still apply in
fido land these days with internet comms used for most if not all
sysops ?
there never was a limit on message size... what everyone has been
seeing is arbitrary limits placed by ""lazy"" coders*... the tech
standard states that message bodies are unbounded which means there is
no limit set... this leaves plenty of room for expansion as technology grows... we can see this by this very 64k barrier... it used to be
32k... these days, memory is accessed differently and the barrier is
much much larger... effectively, each system is limited by drive
space*N where N is the number of copies of the message a system makes
when processing the message... copies because of sending to other
systems in a distribution system (eg: fidonet)...
* ""lazy"" coders: those who didn't implement some sort of disk-based overflow system so they could process messages too large to fit into
the memory allocation scheme of the time... sure, the larger messages
would be processed slower but they would be processed and passed on...
no need for splitting... splitting should be done only when the
messages are stored in a local message base that has arbitrary message
size limits in place... split the message when initially stored... reassemble it into one when exporting it to other systems (eg: they rescanned the area)... the ^ASPLIT spec is perfect for this but some
chose to use it at another point in the process...
)\/(ark
Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer
doin' it wrong...
... The road to success is often under construction...
On 2017 Oct 25 14:36:30, you wrote to Andrew Leary:
In the future, I can look at possibly splitting large replies
into multiple messages.
In mbse there is a 60/64k message limit does this still apply in
fido land these days with internet comms used for most if not all
sysops ?
there never was a limit on message size... what everyone has been
seeing is arbitrary limits placed by ""lazy"" coders*... the tech
standard states that message bodies are unbounded which means there is
no limit set... this leaves plenty of room for expansion as technology grows... we can see this by this very 64k barrier... it used to be
32k... these days, memory is accessed differently and the barrier is
much much larger... effectively, each system is limited by drive
space*N where N is the number of copies of the message a system makes
when processing the message... copies because of sending to other
systems in a distribution system (eg: fidonet)...
* ""lazy"" coders: those who didn't implement some sort of disk-based overflow system so they could process messages too large to fit into
the memory allocation scheme of the time... sure, the larger messages
would be processed slower but they would be processed and passed on...
no need for splitting... splitting should be done only when the
messages are stored in a local message base that has arbitrary message
size limits in place... split the message when initially stored... reassemble it into one when exporting it to other systems (eg: they rescanned the area)... the ^ASPLIT spec is perfect for this but some
chose to use it at another point in the process...
Mbse has a fixed limit of 60 and 64, so short of changing the code I
am stuck.
Hello Vince!
24 Oct 17 21:43, you wrote to all:
Found it and it in mbfido/filefind.c
There are four settings :
----
/*
* The next constants are to prevent overflowing the echomail
areas
* with huge replies. MAX_DESC_LINES limits the number of file
description * lines, 5 should be enough. The other two are the
maximum files to report * if in the same area or different area.
* For netmail replies there is a different limit. */ #define
MAX_DESC_LINES 5 #define MAX_FILES_SAMEBOARD 25
#define MAX_FILES_OTHERBOARD 50 #define MAX_FILES_NETMAIL
100
----
Andrew is there any way we can change these as a param for
configure or better still within the system set up params ?
We can probably do something about that without too much trouble. As
with anything, sysops will need to use common sense in setting limits
to prevent gigantic echomail messages.
In the future, I can look at possibly splitting large replies into
multiple messages.
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,045 |
| Nodes: | 15 (1 / 14) |
| Uptime: | 63:47:16 |
| Calls: | 500,408 |
| Calls today: | 11 |
| Files: | 95,209 |
| D/L today: |
1,682 files (496M bytes) |
| Messages: | 465,011 |
| Posted today: | 2 |