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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)