Hello Alex!

01 Jun 25, Alex Galiyev wrote to Tommi Koivula:

Perhaps the "DateArrived". I %rescanned from the boss, set -p 30,
but it doesn't purge.

That's a good catch! Because I rescanned the messages from my uplink
just recently, so it definitely uses the message arrival date, instead
of the written date.

This seems like a bug

It depends. What is the purpose of pack and purging? In the past it was saving space on an overfilled Node/BBS. What is the purpose of re-scanning? To fetch all available msg, but why? To read the "new" echoarea with history and have a good background when entering discussion? Or to delete the "new" msg unseen?

From my point of view the "date arrived" is the fail save configuration. The set of husky software is basically a node software. A node can have points and supply them with messages. A default configuration should make sure that messeages are available. For todays Fidonet traffic we may have areas that receive no messages for weeks. And we may have node system failures for days. Any downtime would shorten the time of message availibiliy if the date.written methode is used. The date.arrived would make sure that a message is available for the full pre-purge time.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Hello Alex!

01 Jun 25, Alex Galiyev wrote to Tommi Koivula:

The binary became 214Kb larger, no thanks. =)

Would you like to tell us your system environment?
Or is that just a principle?

--- GoldED+/W64-MSVC 1.1.5-b20250409

I can't imagine that a W64 system have a problem with 214k. You have a single event usage, one purge after %rescan. After that purge is done the incoming date_written and the date_arrived are close next to each other. You could continue with the smaller sqpack then.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Hello Kai!

Tuesday June 03 2025 12:21, you wrote to me:

was saving space on an overfilled Node/BBS. What is the purpose of re-scanning? To fetch all available msg, but why? To read the "new"

When you just got your node setup for the first time, there are zero messages in every area.

You need to see the past conversations, rules, so you can start with something.

Or if you lost all data/squish corruption, whatever.

This is the reason for rescan. It's a great feature.

Alex

--- GoldED+/W64-MSVC 1.1.5-b20250409
* Origin: Glory to Ukraine! Glory to Heroes! Dump Trump! (1:129/14.1)

Hello Kai!

Tuesday June 03 2025 12:21, you wrote to me:

I can't imagine that a W64 system have a problem with 214k.

This is not about the size, I suspect a trojan in there, can't be such a significant growth.

Alex

--- GoldED+/W64-MSVC 1.1.5-b20250409
* Origin: Glory to Ukraine! Glory to Heroes! Dump Trump! (1:129/14.1)

On 3.6.2025 19.40, Alex Galiyev wrote:

I can't imagine that a W64 system have a problem with 214k.

This is not about the size, I suspect a trojan in there, can't be such a significant growth.

Of course there is one. Or maybe two! :D

I don't know what version you are using, but it's all about compiling.

The version I compiled is : "sqpack/w32-mvc 1.9 2025-06-01".

file sqpack.exe
sqpack.exe: PE32 executable (console) Intel 80386, for MS Windows, 4 sections

'Tommi

--- FastEcho/2 1.46.1 Revival
* Origin: nntp://rbb.fidonet.fi - Finland (2:221/360.0)

Hello Tommi!

Tuesday June 03 2025 20:28, you wrote to me:

Of course there is one. Or maybe two! :D

I knew it. =))))

I don't know what version you are using, but it's all about compiling.
The version I compiled is : "sqpack/w32-mvc 1.9 2025-06-01".

I don't think that a real dated version. Which repo are you suing?

BTW: Do you know how to extract message from squish areas to text files using native husky tools, I tried use SMAPI, but it seems to be outdated.

Alex

--- GoldED+/W64-MSVC 1.1.5-b20250409
* Origin: Glory to Ukraine! Glory to Heroes! Dump Trump! (1:129/14.1)

Hello Alex!

03 Jun 25, Alex Galiyev wrote to Kai Richter:

When you just got your node setup for the first time, there are zero messages in every area.

Same goes for long time existing nodes that add an echoarea for the first time.

This is the reason for rescan. It's a great feature.

For sure. The sqpack bug question should ask what happend to a long time existing node that added a very old echoarea with thousands of messages but didn't have activity for months?

I do assume that long time existing nodes do have some level of automation and that they run daily mainenance procedures like sqpack.

With a purge time of 30 days and a date_written trigger the new 1000s messages echo will be wiped at the first sqpack schedule completely.

data_arrived would make sure that the "new" old messages are available for 30 days and will be rescanable by the nodes downlinks within this period.

With a "network" point of view the date_arrived is no bug, it's a reliability feature.

Regards



Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Hello Alex!

03 Jun 25, Alex Galiyev wrote to Kai Richter:

I can't imagine that a W64 system have a problem with 214k.

This is not about the size, I suspect a trojan in there, can't be such
a significant growth.

I don't know if the windows compiler can handle .dll vs static builds for the fidonet software.

You can find the switch DYNLIBS in the huskymak.cfg of the huskybse module.

For my linux system i can compile with static or shared objects/libraries.

These libs share objects (functions) for programs. To access the squish msgbase there is a libsmapi.so on my system. Programms that read and write to the squish msgbase, like hpt, htick or sqpack, use the smapi functions in the libsmapi.so.

I found my old comparison of the static and dynamic method. For sqpack:

sqpack 24440 Jul 4 2023
sqpack 236992 Sep 24 2023

The last one is the static build. All functions of the libsmapi.so (and other .so libs) are included in the program itself.

Pro & Contra

Dynamic builds: Small programs. Share functions in memory = less memory usage. Library file version must match the programs need.

Static builds: Bigger programs. Functions loaded per program = increased memory usage. Program has all functions included and does not need a matching library.

Today i prefer static builds for fidonet software. Memory is no longer a problem. But the compatibliliy if you need to move an ftn installation to another system is going to be important. Especially if it's a more modern system, with a new compiler version that has improvements that are not compatible with the old source code.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Hi Alex.

05 Jun 25 00:13:28, you wrote to me:

I don't know what version you are using, but it's all about
compiling. The version I compiled is : "sqpack/w32-mvc 1.9
2025-06-01".

I don't think that a real dated version.

Ok.

'Tommi

--- GoldED+/W64-MSVC 1.1.5-b20250409
* Origin: rbb.fidonet.fi (2:221/360)

Hello Alex!

05 Jun 25, Alex Galiyev wrote to Tommi Koivula:

BTW: Do you know how to extract message from squish areas to text
files using native husky tools, I tried use SMAPI, but it seems to be

I never had a reason to do that and i can't imagine one. A native husky method could be msged to read the message and the console function copy paste to put it in the destination. Is that acceptable for you and if not, what do you want to achieve?

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)