• Filefind file limit

    From Vince Coen@2:250/1 to All on Thu Sep 21 20:27:22 2017
    Hello All!

    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.

    Vince

    --- Mageia Linux v5/Mbse v1.0.7.2/GoldED+/LNX 1.1.501-b20150715
    * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)
  • From Vince Coen@2:250/1 to All on Tue Oct 24 21:43:01 2017
    Hello All!

    Thursday September 21 2017 20:27, I wrote to you:


    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 ?



    Vince

    --- Mageia Linux v5/Mbse v1.0.7.2/GoldED+/LNX 1.1.501-b20150715
    * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)
  • From Andrew Leary@1:320/219 to Vince Coen on Tue Oct 24 23:50:50 2017
    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.

    Andrew

    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Vince Coen@2:250/1 to Andrew Leary on Wed Oct 25 14:36:30 2017
    Hello Andrew!

    Tuesday October 24 2017 23:50, you wrote to me:

    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 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 ?


    Vince

    --- Mageia Linux v5/Mbse v1.0.7.2/GoldED+/LNX 1.1.501-b20150715
    * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)
  • From mark lewis@1:3634/12.73 to Vince Coen on Wed Oct 25 11:10:16 2017
    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...
    ---
    * Origin: (1:3634/12.73)
  • From Vince Coen@2:250/1 to mark lewis on Wed Oct 25 22:50:07 2017
    Hello mark!

    Wednesday October 25 2017 11:10, you wrote to me:

    Thanks for that and I will increase my system limit if possible.

    Vince


    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...


    Vince

    --- Mageia Linux v5/Mbse v1.0.7.2/GoldED+/LNX 1.1.501-b20150715
    * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)
  • From Vince Coen@2:250/1 to mark lewis on Tue Oct 31 17:47:20 2017
    Hello mark!

    Wednesday October 25 2017 11:10, you wrote to me:

    Mbse has a fixed limit of 60 and 64, so short of changing the code I am stuck.

    It was only an idea any way of reducing resources.


    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...


    Vince

    --- Mageia Linux v5/Mbse v1.0.7.2/GoldED+/LNX 1.1.501-b20150715
    * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)
  • From mark lewis@1:3634/12.73 to Vince Coen on Tue Oct 31 14:27:00 2017

    On 2017 Oct 31 17:47:20, you wrote to me:

    Mbse has a fixed limit of 60 and 64, so short of changing the code I
    am stuck.


    yeah, i kinda figured it might turn out like that... something like this (built
    in limits) generally does...


    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Character is what you know you are, not what others think you are.
    ---
    * Origin: (1:3634/12.73)
  • From Vince Coen@2:250/1 to Andrew Leary on Sat Dec 2 13:00:21 2017
    Hello Andrew!

    Tuesday October 24 2017 23:50, you wrote to me:

    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 meanwhile I have sets these as :

    #define MAX_DESC_LINES 10
    #define MAX_FILES_SAMEBOARD 100
    #define MAX_FILES_OTHERBOARD 200
    #define MAX_FILES_NETMAIL 500

    Although not tested as no one has used it, figgers .

    Vince

    --- Mageia Linux v5.1/Mbse v1.0.7.4/GoldED+/LNX 1.1.501-b20150715
    * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)