1. Forum
  2. FidoNet
  3. FIDOSOFT.HUSKY

  • sqpack doesn't purge

    From Alex Galiyev@1:129/14.1 to All on Sat May 31 12:52:07 2025
    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)
  • From Tommi Koivula@2:221/10 to Alex Galiyev on Sat May 31 21:05:41 2025
    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)
  • From Jay Harris@1:229/664 to Alex Galiyev on Sat May 31 15:04:34 2025
    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)
  • From Alex Galiyev@1:129/14.1 to Tommi Koivula on Sat May 31 15:08:39 2025
    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)
  • From Alex Galiyev@1:129/14.1 to Jay Harris on Sat May 31 15:27:15 2025
    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)
  • From Kai Richter@2:240/77 to Alex Galiyev on Tue Jun 3 12:21:22 2025
    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)
  • From Kai Richter@2:240/77 to Alex Galiyev on Tue Jun 3 12:21:26 2025
    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)
  • From Alex Galiyev@1:129/14.1 to Kai Richter on Tue Jun 3 12:38:16 2025
    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)
  • From Alex Galiyev@1:129/14.1 to Kai Richter on Tue Jun 3 12:40:46 2025
    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)
  • From Tommi Koivula@2:221/360 to Alex Galiyev on Tue Jun 3 20:28:27 2025
    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)
  • From Alex Galiyev@1:129/14.1 to Tommi Koivula on Thu Jun 5 00:13:29 2025
    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)
  • From Kai Richter@2:240/77 to Alex Galiyev on Thu Jun 5 17:34:54 2025
    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)
  • From Kai Richter@2:240/77 to Alex Galiyev on Thu Jun 5 17:51:28 2025
    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)
  • From Kai Richter@2:240/77 to Alex Galiyev on Fri Jun 13 22:59:04 2025
    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)