On 2019 Apr 05 12:46:20, you wrote to me:

0148 0000 0148 0000

if i've done my math properly, these both point to your last and
highest read message numbers in that area as being 328...

Correct ... but this still does not change anything with my original problem that the unread flag is not reset when I read a mail in goated ;)

right... we figured out what you were really trying to say in a later post :)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... She wore a grey bathing suit & Greenpeace tried to tow her to the sea.
---
* Origin: (1:3634/12.73)

Hello Richard Menedetter!

05 Apr 19 12:46:20, Richard Menedetter wrote to mark lewis:

if i've done my math properly, these both point to your last and
highest read message numbers in that area as being 328...

Correct ... but this still does not change anything with my original

problem that the unread flag is not reset when I read a mail in goated ;)
user, which run goated can write in JLR file?

Alexander


--- ════════╦╦═╦╦═╗╔════
* Origin: ═╩══╬╩═╩╩═╬╬═ (2:5020/9696.128)

Hi Alexander!

05 Apr 2019 20:51, from Alexander N. Skovpen -> Richard Menedetter:

if i've done my math properly, these both point to your last and
highest read message numbers in that area as being 328...

Correct ... but this still does not change anything with my
original problem that the unread flag is not reset when I read a
mail in goated ;)

user, which run goated can write in JLR file?

Yes ... golded and goated are run from the same user.

But let me restate the issue.

I get new messages.
I read them in goated.
The lastread counter will show 0 unread messages, but the messages that I did read in goated are still marked UNREAD in golded.
So the lastread pointer is updated, but the messages themselves still show up as unread in golded. (unread flag not reset?)

I hope I made it a bit clearer.

CU, Ricsi

... Behaviour is the mirror in which everyone shows their image.
--- GoldED+/LNX
* Origin: Don't judge the parade by a few clowns. (2:310/31)

On 2019 Apr 05 20:51:26, you wrote to Richard Menedetter:

Correct ... but this still does not change anything with my original
problem that the unread flag is not reset when I read a mail in
goated ;)

user, which run goated can write in JLR file?

the problem seems to be that when RM reads a message addressed to him, it should be marked as received... when he switches to the other reader using the same message base files, that same message is not marked received... i have not
asked RM if this is seen only when going from goated to golded or if he sees the problem when reading with golded first and then goated...

ideally, when one package marks the message as received, both packages should see the message marked as received... received as in the intended recipient has
read the message whether it is netmail or echomail...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... There's gin in my martini? No wonder I'm pissed.
---
* Origin: (1:3634/12.73)

Hi mark!

05 Apr 2019 15:09, from mark lewis -> Alexander N. Skovpen:

the problem seems to be that when RM reads a message addressed to him,
it should be marked as received... when he switches to the other
reader using the same message base files, that same message is not
marked received...

Correct ... except all messages not only those addressed to me.

i have not asked RM if this is seen only when going
from goated to golded or if he sees the problem when reading with
golded first and then goated...

Unread messages are marked in a different color in the message lister.
Goated does not have a message lister, so I do not know if it would show them as unread.

CU, Ricsi

... If you're as old as you feel, how could I be alive at 150?
--- GoldED+/LNX
* Origin: Use tasteful words. You might have to eat them. (2:310/31)

On 2019 Apr 07 09:56:38, you wrote to me:

the problem seems to be that when RM reads a message addressed to him,
it should be marked as received... when he switches to the other
reader using the same message base files, that same message is not
marked received...

Correct ... except all messages not only those addressed to me.

OH! then they are not ""marked received""... that's with the received attribute
bit in the message header and only if the name matches the user's name... i got
confused with your use of the phrase "marked received" or "marked read"... messages aren't marked read or received in general...

i have not asked RM if this is seen only when going from goated to
golded or if he sees the problem when reading with golded first and
then goated...

Unread messages are marked in a different color in the message lister.

right... so the problem does appear to be something with the last/high read pointers, then... that's weird because the JLR data you sent seems to have been
done properly... i'm assuming that you do only have 328 (or whatever that number was) messages in the area in question? now i'm curious about that JLR data again and which of the two programs was the last one used which would have
written those counters to the file...

can you take a snapshot of the JLR file before you do any reading at all?
then read with one of the programs, exit, and take another snapshot of the JLR file?
and lastly read with the other program, exit, and take a 3rd snapshot of the JLR file?

maybe then we can see if the pointers are being properly updated...

Goated does not have a message lister, so I do not know if it would
show them as unread.

ok...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Money is flat and meant to be piled up. - Scotch Proverb
---
* Origin: (1:3634/12.73)

Hi mark!

07 Apr 2019 06:28, from mark lewis -> Richard Menedetter:

On 2019 Apr 07 09:56:38, you wrote to me:

the problem seems to be that when RM reads a message addressed
to him, it should be marked as received... when he switches to
the other reader using the same message base files, that same
message is not marked received...

Correct ... except all messages not only those addressed to me.

OH! then they are not ""marked received""... that's with the received attribute bit in the message header and only if the name matches the user's name... i got confused with your use of the phrase "marked received" or "marked read"... messages aren't marked read or received
in general...

Let me rephrase.

1 READ
2 READ <- LASTREAD POINTER
3 UNREAD
4 UNREAD

If I read them in golded all will be marked read, and the lastread pointer will
point to the last message (4).
If I read them in goated, it will updated the lasterad pointer, but the messages are still shown as unread.

1 READ
2 READ
3 UNREAD
4 UNREAD <- LASTREAD POINTER

So the unread pointer is updated, but the messages in the JAM base are not marked as read.
(and show up in a different color, as golded sees them as unread)

right... so the problem does appear to be something with the last/high read pointers

No, the lastread pointer is updated correctly.

seems to have been done properly... i'm assuming that you do only have
328 (or whatever that number was) messages in the area in question?
now i'm curious about that JLR data again and which of the two
programs was the last one used which would have written those counters
to the file...

The JLR file is fine.

CU, Ricsi

... If you really want to be depressed, weigh yourself in grams.
--- GoldED+/LNX
* Origin: If ignornace is bliss, you ought to be ecstatic. (2:310/31)

On 2019 Apr 07 14:51:34, you wrote to me:

Let me rephrase.

1 READ
2 READ <- LASTREAD POINTER
3 UNREAD
4 UNREAD

ok...

If I read them in golded all will be marked read,

ok, technically, they're not "marked as read"... their message number is simply
less than or equal to the lastread pointer in the JLR file... since their message number is less than or equal to the lastread pointer, they are drawn in
GoldED with a different color... AFAIK, that's all it is that is doing that different colors thing...

1. how many messages to you actually have in the JAM area in question?
2. what is the lowest message number indicated in GoldED?
3. what is the highest message number indicated in GoldED?
4. has the JAM base had messages deleted from it for being too old?
5. are the message numbers the same between GoldED and GoatED for the same message(s)?

here's where i'm going with this... i'm starting to wonder if the base message number (aka offset message number) in the JHR is not being accounted for when the JLR file is being written... in other words, if the base message number is 0 then the first message in the base is 1... if the base message number is 250,
then the first message in the base is 251... if this base message number in the JHR file is not being accounted for, then the number written to the JLR file will be too small since it leaves out the base message number... GoldED would think you have not read that high because of this...

NOTE: i may be off by one in the above... i don't recall if a new empty JAM area starts with 0 or 1 as the value in the JHR... the point is that this base message number (aka offset) should be taken into account one way or the other...

1 READ
2 READ
3 UNREAD
4 UNREAD <- LASTREAD POINTER

So the unread pointer is updated, but the messages in the JAM base are not marked as read. (and show up in a different color, as golded sees them as unread)

as above and as we dig more into this problem and gain more details, this would
seem to indicate that the pointer is not being written to the JLR file properly... either that or GoldED is doing something else outside of the JAM spec to keep up with them... we already know that it is doing a WeirdThing<tm> when deleting messages... that weird thing allows the messages to be easily undeleted but it is outside of the JAM spec operation...

right... so the problem does appear to be something with the
last/high read pointers

No, the lastread pointer is updated correctly.

it would seem not if GoldED isn't listing the messages properly... but it could
be something else, as mentioned above...

seems to have been done properly... i'm assuming that you do only
have 328 (or whatever that number was) messages in the area in
question? now i'm curious about that JLR data again and which of the
two programs was the last one used which would have written those
counters to the file...

The JLR file is fine.

do you have another JAM capable local sysop reader you can use to access your JAM bases with? does it show the same problem as GoldED? if you do have one, it
would point more toward where the problem is... maybe try TimED or MsgED?

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... What we have here, is a NEED to communicate!
---
* Origin: (1:3634/12.73)

Hi mark!

07 Apr 2019 13:08, from mark lewis -> Richard Menedetter:

do you have another JAM capable local sysop reader you can use to
access your JAM bases with? does it show the same problem as GoldED?
if you do have one, it would point more toward where the problem is... maybe try TimED or MsgED?

Sorry for my late reply.
That is a good idea!
I have one now.
But how do I get the message lister in MsgEd?
(just compiled it ...)

CU, Ricsi

... Feature: Hardware limitation as described by a marketing representative. --- GoldED+/LNX
* Origin: For sale: Rottweiler. Eats anything. Fond of children. (2:310/31)