• How to increase size limit

    From Ruslan Suleimanov@2:467/888 to All on Wed Jul 1 11:01:20 2020
    Hi, All!




    I find that my some ECHO file size stop on 2048 MB...

    -rw-r--r-- 1 rfido rfido 2147484864 31 мая 02:00 RU.SEX.SIMVOL.sqd


    Now in htp.log:

    -- cut --
    1 19:28:00 Could not open /fido/msgbase/RU.SEX.SIMVOL
    -- cit --



    Please help ! How to up limit ?






    WBR, Ruslan Suleimanov.
    Telegram: @rsuleimanov
    --- GoldED+/FreeBSD/..I LIKE UNIX EVERYDAY..
    * Origin: ---/RS/FIDO Druzi 199x fido.odessa.ua/ (2:467/888)
  • From Ruslan Suleimanov@2:467/888 to Michael Dukelsky on Wed Jul 1 20:19:48 2020
    Hi, Michael!

    Ответ на сообщение Michael Dukelsky (2:5020/1042) к Ruslan Suleimanov, написанное 01 июл 20 в 19:14:

    Wednesday July 01 2020, Ruslan Suleimanov wrote to All:

    I find that my some ECHO file size stop on 2048 MB...

    -rw-r--r-- 1 rfido rfido 2147484864 31 мая 02:00
    RU.SEX.SIMVOL.sqd

    If the file is on FAT32, copy it to some better file system.

    Michael


    No, this file in unix. BSD UFS





    WBR, Ruslan Suleimanov.
    Telegram: @rsuleimanov
    --- GoldED+/FreeBSD/..I LIKE UNIX EVERYDAY..
    * Origin: ---/RS/FIDO Druzi 199x fido.odessa.ua/ (2:467/888)
  • From Michael Dukelsky@2:5020/1042 to Ruslan Suleimanov on Wed Jul 1 20:30:30 2020
    Hello Ruslan,

    Wednesday July 01 2020, Ruslan Suleimanov wrote to Michael Dukelsky:

    I find that my some ECHO file size stop on 2048 MB...
    -rw-r--r-- 1 rfido rfido 2147484864 31 мая 02:00
    RU.SEX.SIMVOL.sqd
    If the file is on FAT32, copy it to some better file system.
    No, this file in unix. BSD UFS

    I don't know whether squish format has such size limit. If not, it could be a corrupt message base. Can you open it in golded or in some other message reader?

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Moscow, Russia (2:5020/1042)
  • From mark lewis@1:3634/12 to Ruslan Suleimanov on Wed Jul 1 13:48:58 2020
    Re: How to increase size limit
    By: Ruslan Suleimanov to All on Wed Jul 01 2020 11:01:20


    I find that my some ECHO file size stop on 2048 MB...

    -rw-r--r-- 1 rfido rfido 2147484864 31 мая 02:00 RU.SEX.SIMVOL.sqd

    IIRC, yes, that's one of the limits of the squish base... it is a design feature/defect...


    )\/(ark
    --- SBBSecho 3.11-Linux
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)
  • From Max Vasilyev@2:5057/77 to Michael Dukelsky on Wed Jul 1 22:13:20 2020
    Hello Michael!

    01 Jul 20 19:14, you wrote to Ruslan Suleimanov:

    I find that my some ECHO file size stop on 2048 MB...
    -rw-r--r-- 1 rfido rfido 2147484864 31 мая 02:00
    RU.SEX.SIMVOL.sqd
    If the file is on FAT32, copy it to some better file system.
    It is not a filesystem problem.
    It is INT_MAX (signed dword) limitation - hardcoded thing for the fidonet.

    WBR, Max. piwamoto!писем-нет
    --- скучаю по FleetStreet'у :-(((
    * Origin: Personal Reality (2:5057/77)
  • From Michael Dukelsky@2:5020/1042 to Max Vasilyev on Wed Jul 1 22:29:14 2020
    Hello Max,

    Wednesday July 01 2020, Max Vasilyev wrote to Michael Dukelsky:

    I find that my some ECHO file size stop on 2048 MB...
    -rw-r--r-- 1 rfido rfido 2147484864 31 мая 02:00
    RU.SEX.SIMVOL.sqd
    If the file is on FAT32, copy it to some better file system.
    It is not a filesystem problem.
    It is INT_MAX (signed dword) limitation - hardcoded thing for the
    fidonet.

    Fidonet is not a code or a msgbase specification. So INT_MAX cannot be hardcoded there. It could be present in squish specification or hardcoded in its implementation. Nobody can forbid implementing a msgbase as a database without such a limitation.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Moscow, Russia (2:5020/1042)
  • From mark lewis@1:3634/12 to Ruslan Suleimanov on Wed Jul 1 15:25:56 2020
    Re: How to increase size limit
    By: Ruslan Suleimanov to mark lewis on Wed Jul 01 2020 21:44:40


    How to change limit or what database better in HTP ?

    you could change the structure of the squish base format but then it would not be squish any more...

    JAM does not have the limitations that squish has... it has its own limitations but they allow for larger areas than most other message base formats...


    )\/(ark
    --- SBBSecho 3.11-Linux
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)
  • From Kai Richter@2:240/77 to Michael Dukelsky on Thu Jul 2 04:26:14 2020
    Hello Michael!

    01 Jul 20, Michael Dukelsky wrote to Max Vasilyev:

    I find that my some ECHO file size stop on 2048 MB...
    If the file is on FAT32, copy it to some better file system.

    Beep. FAT32 file size limit is ~4096 MB. 2GB is FAT16.

    It is INT_MAX (signed dword) limitation - hardcoded thing for the
    fidonet.

    Fidonet is not a code or a msgbase specification.

    Beep. Beep! Beeeep!! Well, the PKT format is no msgbase, but Fidonet is code that is defined in the Fidonet Technology Standard. ;)

    I failed to remember when squish was invented (and i'm to lazy to look for) but FAT32 was late in 1996. I think the limit is to keep compatiblilty to 16-bit platforms.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Oli@2:280/464.47 to Ruslan Suleimanov on Thu Jul 2 10:13:08 2020
    Ruslan wrote (2020-07-01):

    I find that my some ECHO file size stop on 2048 MB...

    -rw-r--r-- 1 rfido rfido 2147484864 31 ╨╝╨░╤П 02:00 RU.SEX.SIMVOL.sqd


    Now in htp.log:

    -- cut --
    1 19:28:00 Could not open /fido/msgbase/RU.SEX.SIMVOL
    -- cit --



    Please help ! How to up limit ?

    In the Squish MsgAPI doc I see only 32 bit unsinged integers used for frame offsets (FOFS). A 32 bit signed integer is not mentioned. The limit should be 4096 MB not 2048 MB. Maybe an implementation issue? If I understand the Squish format correctly it is not possible to have *.sqd files bigger than 4096 MB without breaking compatibility though.

    ---
    * Origin: (2:280/464.47)
  • From Oli@2:280/464.47 to Oli on Thu Jul 2 11:05:10 2020
    Oli wrote (2020-07-02):

    In the Squish MsgAPI doc I see only 32 bit unsinged integers used for
    frame offsets (FOFS). A 32 bit signed integer is not mentioned. The limit should be 4096 MB not 2048 MB. Maybe an implementation issue? If I understand the Squish format correctly it is not possible to have *.sqd files bigger than 4096 MB without breaking compatibility though.

    It seems to be an implementation issue:

    in Squish's msgapi/api_sq.h:
    typedef int32 FOFS;

    in Husky's smapi/api_sq.h:
    typedef hSINT32 FOFS;

    Unfortunately changing that to uint32 wouldn't fix other implementations (Golded uses int32_t).

    Even if the Squish specification says unsigned integer, many applications and libraries use a signed integer for the frame offset (including the reference implementation).

    ---
    * Origin: (2:280/464.47)
  • From Deon George@3:633/509 to mark lewis on Fri Jul 3 11:50:16 2020
    Re: How to increase size limit
    By: mark lewis to Ruslan Suleimanov on Wed Jul 01 2020 03:25 pm

    JAM does not have the limitations that squish has... it has its own limitations but they allow for larger areas than most other message base formats...

    What are the Jam limitations? (Just preparing for what I might be in for...)

    ...ыюхя

    ... It is a rather pleasant experience to be alone in a bank at night.
    --- SBBSecho 3.11-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Oli@2:280/464.47 to Deon George on Fri Jul 3 08:51:38 2020
    Deon wrote (2020-07-03):

    JAM does not have the limitations that squish has... it has its own
    limitations but they allow for larger areas than most other message
    base formats...

    What are the Jam limitations? (Just preparing for what I might be in for...)

    https://defsol.com/news/jammbp-the-joaquim-andrew-mats-message-base-proposal/

    Jam also uses 32 bit for the "offset of text in ????????.JDT file". A JAM base can store more messages than a Squish base as the *.jdt file only includes the text (message body) and not the header, kludge lines and SEEN-BYs. The file size is still limited to 4 GB.

    JAM's uint32 unix time overflows in 2106-02-07, Squish can store dates up to 2107-12-31 (dos time).

    Overall there are not that much different.

    Advantages of Squish:
    It can store a message exactly as received
    All essential data is stored in in the *.sqd file in one piece. Easier to repair.
    Unique message IDs

    Advantages of JAM:
    No message linking limits
    Full 5D (if FTNs would support it)
    Has better support for non-FTN messages (in theory)

    ---
    * Origin: (2:280/464.47)
  • From Wilfred van Velzen@2:280/464 to Oli on Fri Jul 3 09:36:20 2020
    Hi Oli,

    On 2020-07-03 08:51:39, you wrote to Deon George:

    Squish can store dates up to 2107-12-31 (dos time).

    And because of that it has a 2 second resolution. (It drops the least significant bit of the seconds, when it stores a message)
    Which has been causing problems in the net, in the past...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Oli@2:280/464.47 to Wilfred van Velzen on Fri Jul 3 11:22:22 2020
    Wilfred wrote (2020-07-03):

    Hi Oli,

    On 2020-07-03 08:51:39, you wrote to Deon George:

    Squish can store dates up to 2107-12-31 (dos time).

    And because of that it has a 2 second resolution. (It drops the least significant bit of the seconds, when it stores a message) Which has been causing problems in the net, in the past...

    The original time string is preserved and stored in the Squish message base and should be used on rescan. If it's not then it is a problem/bug of the tosser, not really a problem of the Squish format. E.g. Squish (the tosser) does preserve the original date for rescanned/exported messages just fine.

    hpt does write the __ftsc_date field, but does not use it us it for exported messages that are rescanned (as in areafix RESCAN command). Maybe the problems were caused by hpt. Maybe there are other programs that don't stick to the specification. Maybe problems were created by copying / converting messages from JAM to Squish or from Squish to JAM.

    ---
    * Origin: (2:280/464.47)
  • From Wilfred van Velzen@2:280/464 to Oli on Fri Jul 3 11:37:28 2020
    Hi Oli,

    On 2020-07-03 11:22:23, you wrote to me:

    Squish can store dates up to 2107-12-31 (dos time).

    And because of that it has a 2 second resolution. (It drops the least
    significant bit of the seconds, when it stores a message) Which has
    been causing problems in the net, in the past...

    The original time string is preserved and stored in the Squish message base
    and should be used on rescan. If it's not then it is a problem/bug of the tosser, not really a problem of the Squish format. E.g. Squish (the tosser)
    does preserve the original date for rescanned/exported messages just fine.

    hpt does write the __ftsc_date field, but does not use it us it for exported messages that are rescanned (as in areafix RESCAN command). Maybe the problems were caused by hpt. Maybe there are other programs that don't stick to the specification. Maybe problems were created by copying / converting messages from JAM to Squish or from Squish to JAM.

    I don't remember the details, just the problems... ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Stas Mishchenkov@2:460/5858 to Ruslan Suleimanov on Thu Jul 23 11:19:12 2020
    Hi, Ruslan!

    03 июл 20 00:02, Ruslan Suleimanov -> mark lewis:

    Ok, will be use JAM. Thanks.

    However, I would still recommend using the sqpack -c hpt.cfg RU.SEX.SIMVOL command daily. And in the echoconference configuration use the -p 48 option. Is it so important to store UUE for more than one and a half months in the database? You can also use https://github.com/huskyproject/hpt/blob/master/misc/uue.pm for automatic decoding.

    Have nice nights.
    Stas Mishchenkov.

    --- Муж без жены - как дуб без дятла.
    * Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)