• goated

    From mark lewis@1:3634/12.73 to Richard Menedetter on Fri Apr 5 12:41:30 2019
    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)
  • From Alexander N. Skovpen@2:5020/9696.128 to Richard Menedetter on Fri Apr 5 20:51:26 2019
    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)
  • From Richard Menedetter@2:310/31 to Alexander N. Skovpen on Fri Apr 5 20:52:08 2019
    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)
  • From mark lewis@1:3634/12.73 to Alexander N. Skovpen on Fri Apr 5 15:09:34 2019
    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)
  • From Richard Menedetter@2:310/31 to mark lewis on Sun Apr 7 09:56:38 2019
    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)
  • From mark lewis@1:3634/12.73 to Richard Menedetter on Sun Apr 7 06:28:58 2019

    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)
  • From Richard Menedetter@2:310/31 to mark lewis on Sun Apr 7 14:51:34 2019
    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)
  • From mark lewis@1:3634/12.73 to Richard Menedetter on Sun Apr 7 13:08:28 2019
    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)
  • From Richard Menedetter@2:310/31 to mark lewis on Mon Apr 15 09:39:58 2019
    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)