I have a message reader script for Synchronet that I've written in JavaScript. I've written it so that when the user reads a message that was written to them, it will mark the message as read (by setting the MSG_READ attribute). I'm using the put_msg_header() function to save a header with that attribute, and it seems there are some cases where put_msg_header() fails to save the header. I am checking to ensure the message was written to the user, so I don't think that would be the issue.. I did notice that one area where saving the header is failing is a FidoNet area - I'm not sure if that matters though.

This is how I enable the read attribute (msgHeader is the message header object):

msgHeader.attr |= MSG_READ;

I've tried calling put_msg_header a few different ways, using the message number vs. message offset:

msgbase.put_msg_header(true, msgHeader.offset, msgHeader); msgbase.put_msg_header(false, msgHeader.number, msgHeader); msgbase.put_msg_header(msgHeader.number, msgHeader);

I tried the 3rd one since the first parameter is optional (according to the Synchronet JS docs); I've also seen examples that omit the first parameter and just use the message number. Where it fails, I will exit my message reader and then read message again, and it thinks the message has not been read. I've also seen put_msg_header() return false in that case.

Why might put_msg_header() fail?

Nightfox

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com

Re: MsgBase.put_msg_header() failing to save header
By: Nightfox to All on Tue Aug 09 2016 09:05 pm

I have a message reader script for Synchronet that I've written in JavaScript. I've written it so that when the user reads a message that was written to them, it will mark the message as read (by setting the MSG_READ attribute). I'm using the put_msg_header() function to save a header with that attribute, and it seems there are some cases where put_msg_header() fails to save the header. I am checking to ensure the message was written to the user, so I don't think that would be the issue.. I did notice that one area where saving the header is failing is a FidoNet area - I'm not sure if that matters though.

This is how I enable the read attribute (msgHeader is the message header object):

msgHeader.attr |= MSG_READ;

I've tried calling put_msg_header a few different ways, using the message number vs. message offset:

msgbase.put_msg_header(true, msgHeader.offset, msgHeader); msgbase.put_msg_header(false, msgHeader.number, msgHeader); msgbase.put_msg_header(msgHeader.number, msgHeader);

All 3 of those syntaxes should work, assuming the parameters are correct.

I tried the 3rd one since the first parameter is optional (according to the Synchronet JS docs); I've also seen examples that omit the first parameter and just use the message number. Where it fails, I will exit my message reader and then read message again, and it thinks the message has not been read. I've also seen put_msg_header() return false in that case.

Why might put_msg_header() fail?

For a number of reasons. Try printing the msgbase.status and msgbase.error values when whever put_msg_header() fails along with the parameter values you're passing to put_msg_header(), and then share the results here. That'll help to isolate the cause of the error.

digital man

Synchronet/BBS Terminology Definition #1:
ANSI = American National Standards Institute
Norco, CA WX: 63.5øF, 89.0% humidity, 1 mph SE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: MsgBase.put_msg_header() failing to save header
By: Digital Man to Nightfox on Wed Aug 10 2016 01:12:10

Why might put_msg_header() fail?

For a number of reasons. Try printing the msgbase.status and msgbase.error values when whever put_msg_header() fails along with the parameter values you're passing to put_msg_header(), and then share the results here. That'll help to isolate the cause of the error.

This is the status and error message I'm getting when it fails to save the message:
Status: -101
Error: illegal header length increase: 770 (4 blocks) vs 752 (3 blocks)

I get the same error whether I use the message number or offset. The parameters I'm passing to msgbase.put_msg_header are false, 2289, and the header object containing these values:
attr: 0
to: Eric Oulashin
from: robert wolfe
offset: 730
when_written_time: 1465744314
when_written_zone_offset: -300
when_imported_zone_offset: -480
auxattr: 0
netattr: 0
subject: BBS software for Mac OS X
id: <575D6BE8.2289.fido_bbscarni@digitaldistortionbbs.com>
reply_id: <57559F2C.2255.fido_bbscarni@digitaldistortionbbs.com>
from_net_addr: 1:116/17
number: 2289
to_net_type: 0
to_agent: 0
from_net_type: 2
from_agent: 0
replyto_net_type: 0
replyto_agent: 0
ftn_msgid: 1:116/17 48cc417b
ftn_reply: 2255.fido_bbscarni@1:340/7 1bbaddfb
ftn_area: BBS_CARNIVAL
ftn_tid: Mystic BBS 1.12 A16
date: Sun, 12 Jun 2016 08:11:54 -0500
when_written_zone: 16684
when_imported_time: 1465740264
when_imported_zone: 16864
thread_id: 2239
thread_next: 0
thread_first: 0
field_list: [object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
forwarded: 0
expiration: 0
priority: 0
cost: 0
type: 0
version: 289
thread_back: 2255
delivery_attempts: 0
last_downloaded: 0
times_downloaded: 0
data_length: 582
can_read: true

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com

Re: MsgBase.put_msg_header() failing to save header
By: Nightfox to Digital Man on Wed Aug 10 2016 07:17 pm

Re: MsgBase.put_msg_header() failing to save header
By: Digital Man to Nightfox on Wed Aug 10 2016 01:12:10

Why might put_msg_header() fail?

For a number of reasons. Try printing the msgbase.status and msgbase.error values when whever put_msg_header() fails along with the parameter values you're passing to put_msg_header(), and then share the results here. That'll help to isolate the cause of the error.

This is the status and error message I'm getting when it fails to save the message:
Status: -101
Error: illegal header length increase: 770 (4 blocks) vs 752 (3 blocks)

This means that the modified message header requires more storage (blocks in the *.shd file) than what was allocated for the original message header. The read header used 752 bytes (3 256-byte blocks) and the modified header requires 770 bytes (4 256-byte blocks). Setting the "read" attribute should not increase the storage space for a header at all, so something else is changing between when you read the header and when you're attempting to write it.

I get the same error whether I use the message number or offset. The parameters I'm passing to msgbase.put_msg_header are false, 2289, and the header object containing these values:
attr: 0
to: Eric Oulashin
from: robert wolfe
offset: 730
when_written_time: 1465744314
when_written_zone_offset: -300
when_imported_zone_offset: -480
auxattr: 0
netattr: 0
subject: BBS software for Mac OS X
id: <575D6BE8.2289.fido_bbscarni@digitaldistortionbbs.com>
reply_id: <57559F2C.2255.fido_bbscarni@digitaldistortionbbs.com> from_net_addr: 1:116/17
number: 2289
to_net_type: 0
to_agent: 0
from_net_type: 2
from_agent: 0
replyto_net_type: 0
replyto_agent: 0
ftn_msgid: 1:116/17 48cc417b
ftn_reply: 2255.fido_bbscarni@1:340/7 1bbaddfb
ftn_area: BBS_CARNIVAL
ftn_tid: Mystic BBS 1.12 A16
date: Sun, 12 Jun 2016 08:11:54 -0500
when_written_zone: 16684
when_imported_time: 1465740264
when_imported_zone: 16864
thread_id: 2239
thread_next: 0
thread_first: 0
field_list: [object Object],[object Object],[object Object],[object Object],[object Object],[object Object]

The problem might lie in this field_list. Can you expand this array in your debug output so we can see what's being added to the header?

Also, the dump of the original header would be useful for comparison purposes.

digital man

Synchronet "Real Fact" #78:
Synchronet Match Maker had at one time over 4000 profiles of men and women. Norco, CA WX: 67.3øF, 77.0% humidity, 4 mph SE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: MsgBase.put_msg_header() failing to save header
By: Digital Man to Nightfox on Wed Aug 10 2016 22:00:02

Why might put_msg_header() fail?

For a number of reasons. Try printing the msgbase.status and
msgbase.error values when whever put_msg_header() fails along with
the parameter values you're passing to put_msg_header(), and then
share the results here. That'll help to isolate the cause of the
error.

This is the status and error message I'm getting when it fails to save
the message:
Status: -101
Error: illegal header length increase: 770 (4 blocks) vs 752 (3
blocks)

This means that the modified message header requires more storage (blocks in the *.shd file) than what was allocated for the original message header. The read header used 752 bytes (3 256-byte blocks) and the modified header requires 770 bytes (4 256-byte blocks). Setting the "read" attribute should not increase the storage space for a header at all, so something else is changing between when you read the header and when you're attempting to write it.

My reader script shouldn't do anything that increases the size of the header before I write it. I can double-check my reader to see if it's doing anything to increase the header size though. The odd thing is that it successfully saves the header for some messages but fails this way for others.

The problem might lie in this field_list. Can you expand this array in your debug output so we can see what's being added to the header?

Also, the dump of the original header would be useful for comparison purposes.

I've updated the debug dump to expand field_list.
This is the original header before my reader modifies it:

number: 2289
offset: 727
to: Eric Oulashin
from: robert wolfe
subject: BBS software for Mac OS X
to_agent: 0
from_agent: 0
replyto_agent: 0
to_net_type: 0
from_net_type: 2
from_net_addr: 1:116/17
replyto_net_type: 0
forwarded: 0
expiration: 0
priority: 0
cost: 0
type: 0
version: 289
attr: 0
auxattr: 0
netattr: 0
when_written_time: 1465744314
when_written_zone: 16684
when_written_zone_offset: -300
when_imported_time: 1465740264
when_imported_zone: 16864
when_imported_zone_offset: -480
thread_id: 2239
thread_back: 2255
thread_next: 0
thread_first: 0
delivery_attempts: 0
last_downloaded: 0
times_downloaded: 0
data_length: 582
date: Sun, 12 Jun 2016 08:11:54 -0500
reply_id: <57559F2C.2255.fido_bbscarni@digitaldistortionbbs.com>
id: <575D6BE8.2289.fido_bbscarni@digitaldistortionbbs.com>
ftn_msgid: 1:116/17 48cc417b
ftn_reply: 2255.fido_bbscarni@1:340/7 1bbaddfb
ftn_tid: Mystic BBS 1.12 A16
ftn_area: BBS_CARNIVAL
field_list:
0:
type: 162
data: 14/5 18/200 19/33 34/999 90/1 116/17 18 110 120/331 123/10 500
1:
type: 162
data: 128/187 140/1 218/510 700 222/2 230/150 240/1120 249/303 261/20 38
2:
type: 162
data: 261/100 266/404 267/155 280/1027 282/1056 292/907 908 320/119 219
3:
type: 162
data: 340/400 393/68 73 396/45 712/848 801/161 189 2320/105 303 340/7 10
4:
type: 162
data: 340/100 138/389 340/700 226/50 340/200 101 800 300/6 5 340/0
5:
type: 163
data: 116/17 18 261/38 340/400
can_read: true


And this is the header after it applies the MSG_READ attribute:

number: 2289
offset: 727
to: Eric Oulashin
from: robert wolfe
subject: BBS software for Mac OS X
to_agent: 0
from_agent: 0
replyto_agent: 0
to_net_type: 0
from_net_type: 2
from_net_addr: 1:116/17
replyto_net_type: 0
forwarded: 0
expiration: 0
priority: 0
cost: 0
type: 0
version: 289
attr: 2
auxattr: 0
netattr: 0
when_written_time: 1465744314
when_written_zone: 16684
when_written_zone_offset: -300
when_imported_time: 1465740264
when_imported_zone: 16864
when_imported_zone_offset: -480
thread_id: 2239
thread_back: 2255
thread_next: 0
thread_first: 0
delivery_attempts: 0
last_downloaded: 0
times_downloaded: 0
data_length: 582
date: Sun, 12 Jun 2016 08:11:54 -0500
reply_id: <57559F2C.2255.fido_bbscarni@digitaldistortionbbs.com>
id: <575D6BE8.2289.fido_bbscarni@digitaldistortionbbs.com>
ftn_msgid: 1:116/17 48cc417b
ftn_reply: 2255.fido_bbscarni@1:340/7 1bbaddfb
ftn_tid: Mystic BBS 1.12 A16
ftn_area: BBS_CARNIVAL
field_list:
0:
type: 162
data: 14/5 18/200 19/33 34/999 90/1 116/17 18 110 120/331 123/10 500
1:
type: 162
data: 128/187 140/1 218/510 700 222/2 230/150 240/1120 249/303 261/20 38
2:
type: 162
data: 261/100 266/404 267/155 280/1027 282/1056 292/907 908 320/119 219
3:
type: 162
data: 340/400 393/68 73 396/45 712/848 801/161 189 2320/105 303 340/7 10
4:
type: 162
data: 340/100 138/389 340/700 226/50 340/200 101 800 300/6 5 340/0
5:
type: 163
data: 116/17 18 261/38 340/400
can_read: true



Nightfox

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com

Re: MsgBase.put_msg_header() failing to save header
By: Nightfox to Digital Man on Mon Aug 15 2016 08:08 pm

Re: MsgBase.put_msg_header() failing to save header
By: Digital Man to Nightfox on Wed Aug 10 2016 22:00:02

Why might put_msg_header() fail?

For a number of reasons. Try printing the msgbase.status and
msgbase.error values when whever put_msg_header() fails along with DM>> the parameter values you're passing to put_msg_header(), and then DM>> share the results here. That'll help to isolate the cause of the DM>> error.

This is the status and error message I'm getting when it fails to save
the message:
Status: -101
Error: illegal header length increase: 770 (4 blocks) vs 752 (3
blocks)

This means that the modified message header requires more storage (blocks in the *.shd file) than what was allocated for the original message header. The read header used 752 bytes (3 256-byte blocks) and the modified header requires 770 bytes (4 256-byte blocks). Setting the "read" attribute should not increase the storage space for a header at all, so something else is changing between when you read the header and when you're attempting to write it.

My reader script shouldn't do anything that increases the size of the header before I write it.

If you don't pass 'false' as the 3rd argument to MsgBase.get_msg_header(), some header fields are expanded (e.g. missing message-IDs created) and some header fields which are non-existent or blank in the SMB are created in the JS instance of the header. So like the JS object model doc says:
"Pass false for the expand_fields argument (default: true) if you will
be re-writing the header later with put_msg_header()"

digital man

Synchronet/BBS Terminology Definition #5:
BinkD = Binkley Daemon
Norco, CA WX: 83.2øF, 28.0% humidity, 4 mph SE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: MsgBase.put_msg_header() failing to save header
By: Digital Man to Nightfox on Mon Aug 15 2016 21:14:17

If you don't pass 'false' as the 3rd argument to MsgBase.get_msg_header(), some header fields are expanded (e.g. missing message-IDs created) and some header fields which are non-existent or blank in the SMB are created in the JS instance of the header. So like the JS object model doc says: "Pass false for the expand_fields argument (default: true) if you will
be re-writing the header later with put_msg_header()"

Ah, I must have forgotten that note in the JS object model doc. That's what was causing put_msg_header to fail in my reader. Thanks.

Nightfox

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com

Re: MsgBase.put_msg_header() failing to save header
By: Nightfox to Digital Man on Tue Aug 16 2016 07:47 pm

Re: MsgBase.put_msg_header() failing to save header
By: Digital Man to Nightfox on Mon Aug 15 2016 21:14:17

If you don't pass 'false' as the 3rd argument to MsgBase.get_msg_header(), some header fields are expanded (e.g. missing message-IDs created) and some header fields which are non-existent or blank in the SMB are created in the JS instance of the header. So like the JS object model doc says: "Pass false for the expand_fields argument (default: true) if you will
be re-writing the header later with put_msg_header()"

Ah, I must have forgotten that note in the JS object model doc. That's what was causing put_msg_header to fail in my reader. Thanks.

Okay, glad that's resolved. :-)

digital man

Synchronet/BBS Terminology Definition #43:
XOFF = Transmit Off (ASCII 19, Ctrl-S)
Norco, CA WX: 94.8øF, 21.0% humidity, 8 mph ESE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net