Hello All!

Nothing is happening when I run this command, it does "think" for a while, but the old messages are still there.
No errors.

================================
D:\FTN\HPT>sqpack -c config *
sqpack/w64-mvcdll 1.9 2023-02-24
================================

Tried with "*" - same thing.

================================
EchoArea FIDOSOFT.HUSKY D:\FTN\Base\Echos\fidosoft.husky -d "General discussion on Husky Software" -g E -b squish -dupecheck del -dupehistory 14 -p 365 1:129/14
================================

Does anyone have a clue?

Thanks.

Alex

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

Hi Alex.

31 May 25 12:52:06, you wrote to All:

Nothing is happening when I run this command, it does "think" for a
while, but the old messages are still there. No errors.

================================

D:\FTN\HPT>> sqpack -c config *

sqpack/w64-mvcdll 1.9 2023-02-24
================================

Tried with "*" - same thing.

================================
EchoArea FIDOSOFT.HUSKY D:\FTN\Base\Echos\fidosoft.husky -d "General discussion on Husky Software" -g E -b squish -dupecheck del
-dupehistory 14 -p 365 1:129/14
================================

Does anyone have a clue?

If you run tparser, what does it say for that echoarea?

-- cut --
Purging enabled (option "-pack") max (-$m): 9999 msgs purge (-p): 365 days dupeHistory 1100
Options: noTinySB noKillSB noKeepUnread noKillRead noHide noKill noManual pause link noMandatory noDebug noDOSFile pack noCCoff noKeepSB autoAreaPause SBkeepAll
-- cut --

'Tommi

---
* Origin: f10.n221.z2.fidonet.fi (2:221/10)

On 31 May 2025, Alex Galiyev said the following...

Nothing is happening when I run this command, it does "think" for a
while, but the old messages are still there.
No errors.

================================
D:\FTN\HPT>sqpack -c config *
sqpack/w64-mvcdll 1.9 2023-02-24
================================

Try putting the * in quotation marks:
sqpack -c config "*"


Jay

... Old computers make great boat anchors

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: Northern Realms (1:229/664)

Hello Tommi!

Saturday May 31 2025 21:05, you wrote to me:

If you run tparser, what does it say for that echoarea?

-------
FIDOSOFT.HUSKY
Description: General discussion on Husky Software

D:\FTN\Base\Echos\fidosoft.husky Squish Use AKA: 1:129/14.1

DOS Style File (8+3) off (-nodosfile)
Level read (-lr): 0
Level write (-lw): 0
Group - E
Purging enabled (option "-pack") max (-$m): 0 msgs purge (-p): 365 days dupeHistory 14
Options: noTinySB noKillSB noKeepUnread noKillRead noHide noKill noManual pause link noMandatory noDebug noDOSFile pack
noCCoff noKeepSB autoAreaPause noSBkeepAll
Default subscribing option:
DupeCheck: delete
tooOld: 0 days (disabled)
tooNew: 0 days (disabled)
ScanMode: normal
Links:
1:129/14 level 0, read/write/rescan, defLink off, mand. off.
-------

Alex

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

Hello Jay!

Saturday May 31 2025 15:04, you wrote to me:

Try putting the * in quotation marks:
sqpack -c config "*"

Already tried, please read my original message.

Alex

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

Hi Alex.

31 May 25 15:08:38, you wrote to me:

Purging enabled (option "-pack") max (-$m): 0 msgs purge (-p): 365
days dupeHistory 14

Should work then...

I don't know which one of these squish dates it uses :

=== Cut ===
DateWritten : 2025-05-31 15:04:34 (78915ABFh)
DateArrived : 2025-05-31 22:09:04 (B1225ABFh)
=== Cut ===

You could try maximum logging.

In here it seems to work:

=== Cut ===
---------- Sun 01 Jun 2025, sqpack/w64-mvcdll 1.9 2023-02-24
1 07:27:16 Start
C 07:27:16 Purge area binkd (squish)
D 07:27:16 old msg: 12; new msg: 10
D 07:27:16 old size: 21094; new size: 17268
=== Cut ===

However, I don't use sqpack in my main nodes, it always renumbers the msgbase. And that is not good when reading with jam/smapinntpd.

'Tommi

---
* Origin: Point One (2:221/1.1)

Hi Alex.

01 Jun 25 07:31:58, I wrote to you:

I don't know which one of these squish dates it uses :

=== Cut ===
DateWritten : 2025-05-31 15:04:34 (78915ABFh)
DateArrived : 2025-05-31 22:09:04 (B1225ABFh)
=== Cut ===

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

=== Cut ===
sqpack/w64-mvcdll 1.9 2023-02-24
1 07:45:29 Start
C 07:45:29 Purge area fidosoft.husky (squish)
D 07:45:29 old msg: 91; new msg: 91
D 07:45:29 old size: 133461; new size: 133461
E 07:45:29 Total old msg: 91; new msg: 91
E 07:45:29 Total old size: 133461; new size: 133461
1 07:45:29 End
=== Cut ===

'Tommi

---
* Origin: Point One (2:221/1.1)

01 Jun 25 01:08, 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, should I report it on github, will anyone care there? =)

You may try. :)

I requested an option not to renumber messages when packing, but there are not many husky maintainers left when Michael Dukelsky left. :(

'Tommi

---
* Origin: * RBB * Lake Ylo * Finland * (2:221/360)

Hello Tommi!

Sunday June 01 2025 07:46, you wrote to me:

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, should I report it on github, will anyone care there? =)

Alex

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

Hello Tommi!

Sunday June 01 2025 09:24, you wrote to me:

Please test if you wish: https://www.fidonet.fi/pub/sqpack.exe
Works here so far. No warranty. ;)

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

Alex

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

On 1.6.2025 20.26, Alex Galiyev wrote:

Please test if you wish: https://www.fidonet.fi/pub/sqpack.exe
Works here so far. No warranty. ;)

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

Then do compile your own binary.

'Tommi

---
* Origin: smapinntpd/lnx (2:221/1.0)

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)