Virtual Private Server (VPS) Hosting provided by Central Point Networking cpnllc.com
For some reason, the "Nodelist" and "Recent Callers" features are not working.
| Sysop: | Ray Quinn |
|---|---|
| Location: | Visalia, CA |
| Users: | 60 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 64:50:34 |
| Calls: | 12 |
| Files: | 12,938 |
| Messages: | 99,120 |
Check out the US 99 menu above for links to information about US Highway 99, after which the US 99 BBS is named.
Be sure to click on the Amateur Radio menu item above for packet BBSes, packet software, packet organizations, as well as packet how-to's. Also included is links to local and some not-so-local Amateur Radio Clubs.
Nothing is happening when I run this command, it does "think" for a
while, but the old messages are still there. No errors.
================================
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?
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
================================
If you run tparser, what does it say for that echoarea?-------
D:\FTN\Base\Echos\fidosoft.husky Squish Use AKA: 1:129/14.1DOS Style File (8+3) off (-nodosfile)
Try putting the * in quotation marks:Already tried, please read my original message.
sqpack -c config "*"
Purging enabled (option "-pack") max (-$m): 0 msgs purge (-p): 365
days dupeHistory 14
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, butThat'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.
it doesn't purge.
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? =)
Perhaps the "DateArrived". I %rescanned from the boss, set -p
30, but it doesn't purge.
That's a good catch!
DosDate_to_TmDate((SCOMBO *)&(xmsg.date_written), &tmTime);
Please test if you wish: https://www.fidonet.fi/pub/sqpack.exeThe binary became 214Kb larger, no thanks. =)
Works here so far. No warranty. ;)
Please test if you wish: https://www.fidonet.fi/pub/sqpack.exeThe binary became 214Kb larger, no thanks. =)
Works here so far. No warranty. ;)
Perhaps the "DateArrived". I %rescanned from the boss, set -p 30,That's a good catch! Because I rescanned the messages from my uplink
but it doesn't purge.
just recently, so it definitely uses the message arrival date, instead
of the written date.
This seems like a bug
The binary became 214Kb larger, no thanks. =)
--- GoldED+/W64-MSVC 1.1.5-b20250409
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.
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 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! :DI knew it. =))))
I don't know what version you are using, but it's all about compiling.I don't think that a real dated version. Which repo are you suing?
The version I compiled is : "sqpack/w32-mvc 1.9 2025-06-01".
When you just got your node setup for the first time, there are zero messages in every area.
This is the reason for rescan. It's a great feature.
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 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.
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