Hi there

I'm starting to see this error in my logs

3 Dec:04:2022:21:23:21 Linking area NETMAIL
A Dec:04:2022:21:23:21 JAM ERROR: wrongly sized subfield occured!
A Dec:04:2022:21:23:22 JAM ERROR: wrongly sized subfield occured!
A Dec:04:2022:21:23:23 JAM ERROR: subfield is suspiciously large! (1414879828 bytes)
A Dec:04:2022:21:23:23 JAM ERROR: wrongly sized subfield occured!
A Dec:04:2022:21:23:24 JAM ERROR: subfield is suspiciously large! (976302592 bytes)
A Dec:04:2022:21:23:24 JAM ERROR: subfield is suspiciously large! (825360384 bytes)
----------------------- Sun 04 Dec 2022, hpt/lnx 1.9 2022-07-03
1 Dec:04:2022:21:23:25 Start
1 Dec:04:2022:21:23:25 Start packing...
4 Dec:04:2022:21:23:25 EchoTossLogFile not found -> Scanning all areas
4 Dec:04:2022:21:23:25 Scanning NetmailArea NETMAIL
A Dec:04:2022:21:23:25 JAM ERROR: wrongly sized subfield occured!
4 Dec:04:2022:21:23:25 Scanning NetmailArea NETMSG
D Dec:04:2022:21:23:25 Statistics
D Dec:04:2022:21:23:25 areas: 2 msgs: 54
D Dec:04:2022:21:23:25 exported: 0
E Dec:04:2022:21:23:25 Areas summary:
1 Dec:04:2022:21:23:25 End

when I view the message base using GoldED the last 4-5 messages are empty.

is the base corrupt? How best to resolve?

Any tips/advice appreciated.

Best, Paul

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Hello Paul!

04 Dec 22 21:26, you wrote to all:

3 Dec:04:2022:21:23:21 Linking area NETMAIL
A Dec:04:2022:21:23:21 JAM ERROR: wrongly sized subfield occured!
A Dec:04:2022:21:23:22 JAM ERROR: wrongly sized subfield occured!
A Dec:04:2022:21:23:23 JAM ERROR: subfield is suspiciously large! (1414879828 bytes) A Dec:04:2022:21:23:23 JAM ERROR: wrongly sized subfield occured! A Dec:04:2022:21:23:24 JAM ERROR: subfield is suspiciously large! (976302592 bytes) A Dec:04:2022:21:23:24 JAM
ERROR: subfield is suspiciously large! (825360384 bytes) ----------------------- Sun 04 Dec 2022, hpt/lnx 1.9 2022-07-03

[...]

Dec:04:2022:21:23:25 Areas summary: 1 Dec:04:2022:21:23:25 End

when I view the message base using GoldED the last 4-5 messages are
empty.

Do you have a "-$m xxxx" on the line for that area, and have you been running sqpack?



Stephen


--- GoldED+/LNX 1.1.5-b20220409
* Origin: Dragon's Lair BBS, Telnet: dragon.vk3heg.net (3:633/280)

Hi Paul!

Sunday December 04 2022 21:26, you wrote to All:

I'm starting to see this error in my logs

3 Dec:04:2022:21:23:21 Linking area NETMAIL
A Dec:04:2022:21:23:21 JAM ERROR: wrongly sized subfield occured!
A Dec:04:2022:21:23:22 JAM ERROR: wrongly sized subfield occured!
A Dec:04:2022:21:23:23 JAM ERROR: subfield is suspiciously large!

[...skipped...]

when I view the message base using GoldED the last 4-5 messages are
empty.

is the base corrupt? How best to resolve?

Any tips/advice appreciated.

I would recommend storing netmail in OPUS MSG base and using https://brorabbit.g0x.ru/files/perl/maintmsg.pl

Have a nice night.
Stas Mishchenkov.

--- Have You daily sexual life? Hide it proper from Your wife! ;)
* Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)

04 Dec 22 21:26, Paul Hayton wrote to All:

Hi there

I'm starting to see this error in my logs

3 Dec:04:2022:21:23:21 Linking area NETMAIL
A Dec:04:2022:21:23:21 JAM ERROR: wrongly sized subfield occured!
A Dec:04:2022:21:23:22 JAM ERROR: wrongly sized subfield occured!
A Dec:04:2022:21:23:23 JAM ERROR: subfield is suspiciously large! (1414879828 bytes)
A Dec:04:2022:21:23:23 JAM ERROR: wrongly sized subfield occured!
A Dec:04:2022:21:23:24 JAM ERROR: subfield is suspiciously large! (976302592 bytes)
A Dec:04:2022:21:23:24 JAM ERROR: subfield is suspiciously large! (825360384 bytes)
----------------------- Sun 04 Dec 2022, hpt/lnx 1.9 2022-07-03
1 Dec:04:2022:21:23:25 Start
1 Dec:04:2022:21:23:25 Start packing...
4 Dec:04:2022:21:23:25 EchoTossLogFile not found -> Scanning all areas
4 Dec:04:2022:21:23:25 Scanning NetmailArea NETMAIL
A Dec:04:2022:21:23:25 JAM ERROR: wrongly sized subfield occured!
4 Dec:04:2022:21:23:25 Scanning NetmailArea NETMSG
D Dec:04:2022:21:23:25 Statistics
D Dec:04:2022:21:23:25 areas: 2 msgs: 54
D Dec:04:2022:21:23:25 exported: 0
E Dec:04:2022:21:23:25 Areas summary:
1 Dec:04:2022:21:23:25 End

when I view the message base using GoldED the last 4-5 messages are empty.

is the base corrupt? How best to resolve?

I have seen the same. You could try to delete those empty messages with GoldED and then run "sqpack NETMAIL".

'Tommi

---
* Origin: rbb.fidonet.fi (2:221/360)

Hello, Tommi!

Tuesday December 06 2022 21:29, from Tommi Koivula -> Paul Hayton, in URL @OFGHIUrl:

I'm starting to see this error in my logs
A Dec:04:2022:21:23:21 JAM ERROR: wrongly sized subfield occured!
is the base corrupt? How best to resolve?

The JAM base is definitely corrupted here, but the question is how you'vee ended up like this then?

I have seen the same.

Are you guys running some software not compatible with 64bit?
I remember seeing this with the original jamlib which was a part of jamnntpd for example, that only worked on 32-bit machines or you have to compile it with -m32 flag.

You could try to delete those empty messages
with GoldED and then run "sqpack NETMAIL".

That sounds like a workaround in absence of the database fix utility.

Best Regards, Nil
--- GoldED+/LNX 1.1.5
* Origin: -=NIL BBS=- (1:16/101)

On 05 Dec 2022 at 09:55p, Stephen Walsh pondered and said...

Do you have a "-$m xxxx" on the line for that area, and have you been running sqpack?

No and no... I have some learning/reading to do.
I ended up just deleting the base and starting over after copying the files to a temp folder

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

On 05 Dec 2022 at 02:58p, Stas Mishchenkov pondered and said...

Any tips/advice appreciated.

I would recommend storing netmail in OPUS MSG base and using https://brorabbit.g0x.ru/files/perl/maintmsg.pl

thanks will check this out Stas.. :)

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

On 06 Dec 2022 at 09:29p, Tommi Koivula pondered and said...

I have seen the same. You could try to delete those empty messages with GoldED and then run "sqpack NETMAIL".

Thanks for this tip Tommi :)

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Hi Paul!

Wednesday December 07 2022 12:44, you wrote to me:

Any tips/advice appreciated.

I would recommend storing netmail in OPUS MSG base and using
https://brorabbit.g0x.ru/files/perl/maintmsg.pl

thanks will check this out Stas.. :)

I don't know for what reason, but it seems to me that storing netmail in jam or squish is unnatural for it. I've noticed that this isn't the first time that netmail has gotten into trouble with jam or squish.

Have a nice night.
Stas Mishchenkov.

--- Have You daily sexual life? Hide it proper from Your wife! ;)
* Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)

On 07 Dec 2022 at 09:29a, Stas Mishchenkov pondered and said...

I don't know for what reason, but it seems to me that storing netmail in jam or squish is unnatural for it. I've noticed that this isn't the
first time that netmail has gotten into trouble with jam or squish.

Have a nice night.

thanks, yes it's new to me so far had never had any issues until now.

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Hi Nil.

06 Dec 22 15:43:40, you wrote to me:

I'm starting to see this error in my logs
A Dec:04:2022:21:23:21 JAM ERROR: wrongly sized subfield
occured! is the base corrupt? How best to resolve?

The JAM base is definitely corrupted here, but the question is how
you'vee ended up like this then?

Good question indeed. I cannot remember how and when and which system I saw that happening. :(

Are you guys running some software not compatible with 64bit?
I remember seeing this with the original jamlib which was a part of jamnntpd for example, that only worked on 32-bit machines or you have
to compile it with -m32 flag.

JamNNTPd compiled 64bit is broken for sure. I can tell that JamNNTPd works fine in 32bit systems here like OS/2, Raspbian/32bit and Cygwin32. The latest compiled and installed in 64bit windows.

I run SmapiNNTPd/64bit in Debian10/64bit with Golded/64bit and Husky/64bit. All compiled in that system, works fine.

You could try to delete those empty messages
with GoldED and then run "sqpack NETMAIL".

That sounds like a workaround in absence of the database fix utility.

The only problem running SQPACK is that it always renumbers the message base. Not acceptable with nntp clients. :(

'Tommi

---
* Origin: - rbb.fidonet.fi - Finland - (2:221/6)

Hi Stas.

07 Dec 22 09:29:52, you wrote to Paul Hayton:

I don't know for what reason, but it seems to me that storing netmail
in jam or squish is unnatural for it. I've noticed that this isn't
the first time that netmail has gotten into trouble with jam or
squish.

I have never seen JAM related problems in netmail and I have used JAM netmail from day zero with GEcho/GoldED/Concord/Etc...

'Tommi

---
* Origin: - rbb.fidonet.fi - Finland - (2:221/6)

Hello Tommi,

I don't know for what reason, but it seems to me that storing
netmail in jam or squish is unnatural for it. I've noticed that
this isn't the first time that netmail has gotten into trouble
with jam or squish.

I have never seen JAM related problems in netmail and I have used JAM netmail from day zero with GEcho/GoldED/Concord/Etc...

Same here. I don't anymore but used squish netmail bases with Telegard and other software and I never have had any issues.

Ttyl :-),
Al

... Please write your complaint in this box [ ] - Legibly
--- GoldED+/LNX 1.1.5-b20220504
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757.2)

Hi Tommi!

Friday December 09 2022 09:39, you wrote to me:

I don't know for what reason, but it seems to me that storing netmail
in jam or squish is unnatural for it. I've noticed that this isn't
the first time that netmail has gotten into trouble with jam or
squish.

I have never seen JAM related problems in netmail and I have used JAM netmail from day zero with GEcho/GoldED/Concord/Etc...

I can't say that I understand why this is happening. I just noticed that there are regular questions about netmail crashes in JAM or Squish in various echo conferences. And no one has ever complained about MSG.

Have a nice night.
Stas Mishchenkov.

--- Have You daily sexual life? Hide it proper from Your wife! ;)
* Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)

On 11.12.2022 11:38, Stas Mishchenkov wrote:

SM>> I don't know for what reason, but it seems to me that storing netmail
SM>> in jam or squish is unnatural for it. I've noticed that this isn't
SM>> the first time that netmail has gotten into trouble with jam or
SM>> squish.

TK> I have never seen JAM related problems in netmail and I have used JAM
TK> netmail from day zero with GEcho/GoldED/Concord/Etc...

I can't say that I understand why this is happening. I just noticed that there are regular questions about netmail crashes in JAM or Squish in
various echo conferences. And no one has ever complained about MSG.

Hmm, strange. Well this is husky echo, are those questions/complaints related to husky?

'Tommi

---
* Origin: rbb.fidonet.fi - Lake Ylo - Finland (2:221/360)

Hi Tommi!

Sunday December 11 2022 12:03, you wrote to me:

TK> I have never seen JAM related problems in netmail and I have used
JAM
TK> netmail from day zero with GEcho/GoldED/Concord/Etc...

I can't say that I understand why this is happening. I just noticed that
there are regular questions about netmail crashes in JAM or Squish in
various echo conferences. And no one has ever complained about MSG.

Hmm, strange. Well this is husky echo, are those questions/complaints related to husky?

I'm not sure that only with the husky. However, since in Russian-speaking areas this is the most common tosser, then, highly likely, it is most often associated with it.

Have a nice night.
Stas Mishchenkov.

--- Have You daily sexual life? Hide it proper from Your wife! ;)
* Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)

Hello, Tommi Koivula.
On 9/12/22 9:27 you wrote:

The only problem running SQPACK is that it always renumbers the
message base. Not acceptable with nntp clients. :(

Is that because sqpack doesn't have an option to not renumber, or is something about the Squish format itself?

--
Carlos
--- Hotdoged/2.13.5/Android
* Origin: cyberiada mobile point (2:341/234.12)

Hi Carlos.

11 Dec 22 16:00:00, you wrote to me:

The only problem running SQPACK is that it always renumbers the
message base. Not acceptable with nntp clients. :(

Is that because sqpack doesn't have an option to not renumber,

Yes.

something about the Squish format itself?

Nope, Fastecho for example can purge and pack without renumbering. Both JAM and Squish.

'Tommi

---
* Origin: - rbb.fidonet.fi - Finland - (2:221/6)

11 Dec 2022 17:02, you wrote to me:

The only problem running SQPACK is that it always renumbers the
message base. Not acceptable with nntp clients. :(

Is that because sqpack doesn't have an option to not renumber,

Yes.

Is sqpack no longer maintained?

something about the Squish format itself?

Nope, Fastecho for example can purge and pack without renumbering.
Both JAM and Squish.

Ok. I suppose you don't know of any other (standalone) tool that purges Squish bases...

(Just curious - I currently use JAM and FMail so I don't need it.)

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada point (2:341/234.1)

* Originally in FIDOSOFT.HUSKY
* Crossposted in FMAIL_HELP

Hi Carlos.

Is sqpack no longer maintained?

I think it is but nobody seems to be interested in fixing the renumbering issue. :(

something about the Squish format itself?

Nope, Fastecho for example can purge and pack without renumbering.
Both JAM and Squish.

Ok. I suppose you don't know of any other (standalone) tool that purges Squish bases...

I believe not. :(

(Just curious - I currently use JAM and FMail so I don't need it.)

'ftools maint -D' seems to renumber JAM base here. How do you purge messages in JAM without renumbering?

'Tommi

--- FMail-lnx64 2.1.5.0-B20230106
* Origin: -------------------> (2:221/6.600)

Hello Tommi,

Friday January 27 2023, Tommi Koivula wrote to Carlos Navarro:

Is sqpack no longer maintained?

I think it is but nobody seems to be interested in fixing the
renumbering issue. :(

It is not a bug. It is a missing feature. That is why its priority is low.

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Moscow, Russia (2:5020/1042)

Hello, Michael Dukelsky.
On 27/01/2023 16.37 you wrote:

Hello Tommi,
Friday January 27 2023, Tommi Koivula wrote to Carlos Navarro:

Is sqpack no longer maintained?

I think it is but nobody seems to be interested in fixing the
renumbering issue. :(

It is not a bug. It is a missing feature. That is why its priority is low.

Nobody said it is a bug. :)


--
Tommi
--- Hotdoged/2.13.5/Android
* Origin: . (2:221/360.8110)

Tommi wrote (2023-01-27):

(Just curious - I currently use JAM and FMail so I don't need it.)

'ftools maint -D' seems to renumber JAM base here. How do you purge messages in JAM without renumbering?

AFAIK JAM has no "unique message identifier" (UMSGID) like Squish. If you purge messages from the beginning, BaseMsgNum can be set:

This field determines the lowest message number in the index file.
The value for this field is one (1) when a message area is first
created. By using this field, a message area can be packed (deleted
messages are removed) without renumbering it. If BaseMsgNum contains
500, the first index record points to message number 500.

BaseMsgNum has to be taken into account when an application
calculates the next available message number (for creating new
messages) as well as the highest and lowest message number in a
message area.

If you delete messages in the middle you get holes without renumbering.

Solution: use Squish (as in the software).

---
* Origin: War is Peace. Freedom is Slavery. Ignorance is Strength. (2:280/464.47)

Hello, Oli!

Friday January 27 2023 16:55, from Oli -> Tommi Koivula

AFAIK JAM has no "unique message identifier" (UMSGID) like Squish.

You are right, JAM does not call it UMSGID but you can always have a unique message number by adding the basemsgnum value to otherwise 1-based message number. Well, unless you screw up the JAM database by running a broken purge tool which will reset basemsgnum back to 1.

The Husky SMAPI library supports the UMSGID semantic for JAM message base as well. They could have done it more efficiently without reading out the whole index file for renumbering. My min UMSGID would be the basemsgnum. My max UMSGID would be the size of the index file divided by 8 plus the basemsgnum.

If you delete messages in the middle you get holes without
renumbering.

Correct and this is expected behavior.

A similar problem exists in the Usenet world and NNTP protocol (RFC3977). NNTP has to maintain unique message numbers, so the client can save lastread numbers locally, for example .newrc is the most popular file format for that.

NNTP server will report the total number of active messages in the group (similar to "activemsgs" in JAM and "num_msgs" in Squish) and the low and high water mark. What would happen when the message in the middle is deleted? The number of active messages will be decremented but lowest and highest number will stay the same. Deleting from the beginning can be done my increasing the lowest number.

Solution: use Squish (as in the software).

Or write/fix the Jam purge tool which will be purging messages from the beginning and adjusting basemsgnum accordingly but keeping the holes in the middle which is by design there. Squish has introduced doubly linked lists, which is a different design solution for removing messages in the middle. Squish has a drawback though, the fixed array of 9 replies messages in the thread.

Best Regards, Nil
--- GoldED+/LNX 1.1.5
* Origin: -=NIL BBS=- (1:16/101)

'ftools maint -D' seems to renumber JAM base here.

Same here. Wrong assumption.

How do you purge messages in JAM without renumbering?

I don't. Sorry... O:-)

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada point (2:341/234.1)

Hi Nil,

On 2023-01-27 11:08:46, you wrote to Oli:

Squish has a drawback though, the fixed array of 9 replies messages in
the thread.

And it removes the least significant bit of stored dates. So message dates only have even seconds, and thus sometimes messing with dupe checking on other systems, when forwarded messages have been stored in a squish message base before being forwarded to the links of a system. Btw: Hudson has the same problem.

Bye, Wilfred.

--- FMail-lnx64 2.1.5.2-B20230114
* Origin: FMail development HQ (2:280/464)

Wilfred wrote (2023-01-27):

Hi Nil,

On 2023-01-27 11:08:46, you wrote to Oli:

Squish has a drawback though, the fixed array of 9 replies messages
in the thread.

And it removes the least significant bit of stored dates. So message dates only have even seconds, and thus sometimes messing with dupe checking on other systems, when forwarded messages have been stored in a squish message base before being forwarded to the links of a system. Btw: Hudson has the same problem.

You keep repeating that myth. But it's in fact a problem with Husky's Franken-JAM-Squish-SMAPI and a JAM message base rescan / export. Squish bases do store the original header date string (__ftsc_date) which is used on rescans. That is part of the Squish format specification.

The problem is that SMAPI uses the 2-second DOS date format, but there is no __ftsc_date for JAM bases that could be used. IIRC the correct datetime is stored in the JAM base by hpt / SMAPI, it just loses the least significant bit on export.

Squish doesn't have this problem. I tested it with Squish and hpt, no dates were modified. Maybe there is some software that does it wrong, but in all the discussion nobody could name one.

This is also not a problem on pass-through tossing.

---
* Origin: War is Peace. Freedom is Slavery. Ignorance is Strength. (2:280/464.47)

27 Jan 2023 10:48, you wrote to me:

How do you purge messages in JAM without renumbering?

CrashMail II's 'crashmaint PACK' seems to work fine.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

Hi Carlos.

How do you purge messages in JAM without renumbering?

CrashMail II's 'crashmaint PACK' seems to work fine.

Thanks, I'll check it some day.

Does it work ok in Linux/64bit? Jamnntpd does not, and they are related...

'Tommi

---
* Origin: rbb.fidonet.fi (2:221/360)

26 Apr 2023 18:38, you wrote to me:

How do you purge messages in JAM without renumbering?

CrashMail II's 'crashmaint PACK' seems to work fine.

Thanks, I'll check it some day.

Does it work ok in Linux/64bit? Jamnntpd does not, and they are
related...

No idea, sorry. I checked with a Win32 version.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

Tommi wrote (2023-04-26):

Hi Carlos.

How do you purge messages in JAM without renumbering?

CrashMail II's 'crashmaint PACK' seems to work fine.

Thanks, I'll check it some day.

Does it work ok in Linux/64bit? Jamnntpd does not, and they are related...

I haven't tested it, but I believe so. Both are available for Debian in 64-bit. Do we have to file a bug report?

* Origin: This site requires JavaScript (2:280/464.47)

Hi Oli.

Does it work ok in Linux/64bit? Jamnntpd does not, and they are related...

I haven't tested it, but I believe so.

Not good enough for me. Not a matter of religion. :)

Both are available for Debian in 64-bit. Do we have to file a bug
report?

In this debian 64bit I tried "sudo apt install crashmail", then created a very basic crashmail.prefs with one area

area rbb.test.9 2:221/6 jam /bbs/piste/msgbase/rbb.test.9
keepnum 99
keepdays 99

crashmaint maint verbose
Processing rbb.test.9...
0 messages deleted by number, 4278124318 messages left
0 messages deleted by date, 4278124318 messages left

And the jam base is now broken. Hpt cannot work with it, Golded cannot work with it. :(

So yes, we have to file a bug report. Just test by yourself and go ahead.

'Tommi

--- FMail-lnx64 2.2.0.0
* Origin: ------------------------> (2:221/6.600)

* Originally in fidosoft.husky
* Crossposted in jamnntpd

Hi Oli.

Both are available for Debian in 64-bit. Do we have to file a bug
report?

In this debian 64bit I tried "sudo apt install crashmail", then created a very
basic crashmail.prefs with one area

area rbb.test.9 2:221/6 jam /bbs/piste/msgbase/rbb.test.9
keepnum 99
keepdays 99

crashmaint maint verbose
Processing rbb.test.9...
0 messages deleted by number, 4278124318 messages left
0 messages deleted by date, 4278124318 messages left

And the jam base is now broken. Hpt cannot work with it, Golded cannot work
with it. :(

So yes, we have to file a bug report. Just test by yourself and go ahead.

I repeated the same procedure in this Raspian OS 32bit RPI 3B+ system. Works very nice. So 64bit is to blame.

'Tommi

--- GoldED+/LNX 1.1.5-b20220409
* Origin: Linux 6.1.21-v7+ armv7l (2:221/360)

Hello Tommi,

On Sat Apr 29 2023 19:19:30, you wrote to Oli:

Both are available for Debian in 64-bit. Do we have to file a bug
report?

In this debian 64bit I tried "sudo apt install crashmail", then
created a very basic crashmail.prefs with one area

area rbb.test.9 2:221/6 jam /bbs/piste/msgbase/rbb.test.9
keepnum 99
keepdays 99

crashmaint maint verbose
Processing rbb.test.9...
0 messages deleted by number, 4278124318 messages left
0 messages deleted by date, 4278124318 messages left

And the jam base is now broken. Hpt cannot work with it, Golded cannot work with it. :(

So yes, we have to file a bug report. Just test by yourself and go
ahead.

If I'm not mistaken, the crashmail debian stuff was maintained by RJ Clay (as was most FTN related debian packages), who hasn't been around in at *least* 2 years, and a small search does show someone with his name unfortunately passed away on October 28, 2021. The bug report may not go anywhere for you if he was the only person with read/write access. You may want to try one of the forks (or create your own) and proceed from there. Just an FYI.

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- GoldED+/LNX 1.1.5-b20230205
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hi Nicholas.

30 Apr 23 09:35, you wrote to me:

And the jam base is now broken. Hpt cannot work with it, Golded cannot
work with it. :(

So yes, we have to file a bug report. Just test by yourself and go
ahead.

If I'm not mistaken, the crashmail debian stuff was maintained by RJ Clay (as
was most FTN related debian packages), who hasn't been around in at *least* 2
years, and a small search does show someone with his name unfortunately passed
away on October 28, 2021. The bug report may not go anywhere for you if he was
the only person with read/write access. You may want to try one of the forks
(or create your own) and proceed from there. Just an FYI.

Too bad there is broken software in debian repositories...

I think I stay in SMAPI things and JamNNTPd/32bit (and Crashmaint/32bit maybe if really needed).

'Tommi

--- GoldED+/LNX 1.1.5-b20220409
* Origin: Linux 6.1.21-v7+ armv7l (2:221/360)

Nicholas wrote (2023-04-30):

And the jam base is now broken. Hpt cannot work with it, Golded
cannot work with it. :(

So yes, we have to file a bug report. Just test by yourself and go
ahead.

If I'm not mistaken, the crashmail debian stuff was maintained by RJ Clay (as was most FTN related debian packages),

Yes, he was the maintainer.

who hasn't been around in at *least* 2 years,

There are also no github commits after 2019.

and a small search does show someone with his name
unfortunately passed away on October 28, 2021.

which might also be another person.

The bug report may not go anywhere for you if he was the only person
with read/write access.

The bug reports are public. Even if nobody will fix it, we have at least a documentation of the problem. The package is orphaned an maintainer is "Debian QA Group".

https://tracker.debian.org/pkg/crashmail https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982204

You may want to try one of the forks (or create
your own) and proceed from there. Just an FYI.

I think the repository from RJ Clay is the most recent one (but last time I checked as last year, IIRC).

---
* Origin: This site requires JavaScript (2:280/464.47)

Tommi wrote (2023-04-29):

Hi Oli.

Does it work ok in Linux/64bit? Jamnntpd does not, and they are
related...

I haven't tested it, but I believe so.

Not good enough for me. Not a matter of religion. :)

;)

Both are available for Debian in 64-bit. Do we have to file a bug
report?

In this debian 64bit I tried "sudo apt install crashmail", then created a very basic crashmail.prefs with one area

area rbb.test.9 2:221/6 jam /bbs/piste/msgbase/rbb.test.9
keepnum 99
keepdays 99

Had the area been created by crashmail or another tosser?

crashmaint maint verbose
Processing rbb.test.9...
0 messages deleted by number, 4278124318 messages left
0 messages deleted by date, 4278124318 messages left

And the jam base is now broken. Hpt cannot work with it, Golded cannot work with it. :(

Did you try to compare the .j?? files from before and after running crashmaint?

Did you try to run crashmaint a second time over the broken JAM base?

---
* Origin: This site requires JavaScript (2:280/464.47)