• goated

    From Alexander N. Skovpen@2:5020/9696.128 to All on Wed Apr 3 22:51:46 2019
    Hello All!

    i read all wishlists :-)
    i now will be replace UI to other library, then rename goated to GossipEd, then wishlists :-)
    in goated can do only critical bugfixes.


    Alexander


    --- ════════╦╦═╦╦═╗╔════
    * Origin: ═╩══╬╩═╩╩═╬╬═ (2:5020/9696.128)
  • From Richard Menedetter@2:310/31 to Alexander N. Skovpen on Wed Apr 3 20:54:58 2019
    Hello Alexander N. Skovpen!

    03 Apr 19 22:51:46, Alexander N. Skovpen wrote to All:

    i read all wishlists :-)
    ;))

    i now will be replace UI to other library, then rename goated to GossipEd, then wishlists :-)
    in goated can do only critical bugfixes.

    To be honest ... that is a much better name ;)

    PS: just got this crash:
    2019/04/03 22:51:09 goAtEd-linux/amd64 1.0.4-152-634cebd3 started
    panic: runtime error: index out of range

    goroutine 1 [running]:
    github.com/askovpen/goated/pkg/ui.areaPrev(0xc000338090, 0xc0003521e0, 0x8, 0xc000000301)
    c:/gopath/src/github.com/askovpen/goated/pkg/ui/arealist.go:111 +0x751 github.com/askovpen/goated/vendor/github.com/askovpen/gocui.(*Gui).execKeybindings(0xc000338090, 0xc0003521e0, 0xc0 28202, 0x0, 0x0)
    c:/gopath/src/github.com/askovpen/goated/vendor/github.com/askovpen/gocui/gui.go:629 +0xbe
    github.com/askovpen/goated/vendor/github.com/askovpen/gocui.(*Gui).onKey(0xc000338090, 0xc000358dc8, 0xc00000b720, 42e10)
    c:/gopath/src/github.com/askovpen/goated/vendor/github.com/askovpen/gocui/gui.go:593 +0x1b0
    github.com/askovpen/goated/vendor/github.com/askovpen/gocui.(*Gui).handleEvent(0xc000338090, 0xc000358dc8, 0x2, 0x0
    ) /github.com/askovpen/goated/vendor/github.com/askovpen/gocui/gui.go:413 +0x40
    github.com/askovpen/goated/vendor/github.com/askovpen/gocui.(*Gui).MainLoop(0xc000338090, 0x58c798, 0xc00008d450)
    c:/gopath/src/github.com/askovpen/goated/vendor/github.com/askovpen/gocui/gui.go:373 +0x2c3
    main.main()
    c:/gopath/src/github.com/askovpen/goated/goated.go:61 +0x4e1

    c:/gopath/src0xc000200358dc8, 0x5

    Richard

    --- goAtEd-linux/amd64 1.0.4-152-634cebd3
    * Origin: https://github.com/askovpen/goated (2:310/31)
  • From Richard Menedetter@2:310/31 to Alexander N. Skovpen on Wed Apr 3 23:59:28 2019
    Hi Alexander!

    03 Apr 2019 22:51, from Alexander N. Skovpen -> All:

    in goated can do only critical bugfixes.

    I just wanted to display a message and got this message
    "wrong message signature"
    The message opened just fine in Golded.
    No idea what the problem was with GoatEd.

    CU, Ricsi

    ... I'm clinging to sanity by a thread. Hand me those scissors.
    --- GoldED+/LNX
    * Origin: Real programmers aren't afraid to use GOTO's. (2:310/31)
  • From Michiel van der Vlist@2:280/5555 to Richard Menedetter on Wed Apr 3 21:35:57 2019
    Hello Richard Menedetter!

    03 Apr 19 20:54:58, Richard Menedetter wrote to Alexander N. Skovpen:

    PS: just got this crash:
    2019/04/03 22:51:09 goAtEd-linux/amd64 1.0.4-152-634cebd3 started
    panic: runtime error: index out of range


    I have seen something similar, but nothing was written to the log, so I was unable to document it.


    Michiel


    --- goAtEd-windows/386 1.0.4-152-634cebd3
    * Origin: (2:280/5555)
  • From Richard Menedetter@2:310/31 to Alexander N. Skovpen on Thu Apr 4 09:49:30 2019
    Hi Alexander!

    03 Apr 2019 22:51, from Alexander N. Skovpen -> All:

    in goated can do only critical bugfixes.

    I have found that messages that I read in GoatEd are shown as unread in Golded.

    Also I have found this:
    Subj : Trying to connect to the BBS network Corrupted

    Behind the subject line GoatEd wrote Corrupted in bright red. (but it displayed the message correctly.)
    Golded displayed it also correctly, and showed no issues.
    What is going on there?
    Would it help if I try to send you the file?

    Also there seems to be some issues with fidoconfig parsing.
    GoatEd shows more areas then golded.
    They both read the same fidoconfig.
    It does not seem to cause issues.
    (Goated shows eg. echos define and YETI.CC that I do not have ...)

    CU, Ricsi

    ... You are standing in the way of my plan for total world domination!
    --- GoldED+/LNX
    * Origin: Many family trees need trimming. (2:310/31)
  • From Alexander N. Skovpen@2:5020/9696.128 to Richard Menedetter on Thu Apr 4 12:16:24 2019
    Hello Richard Menedetter!

    03 Apr 19 23:59:28, Richard Menedetter wrote to Alexander N. Skovpen:

    in goated can do only critical bugfixes.
    I just wanted to display a message and got this message
    "wrong message signature"
    The message opened just fine in Golded.
    No idea what the problem was with GoatEd.
    in golded press alt-i on this message. maybe corrupted base. sqpack or hptfix to recover.

    Alexander


    --- ════════╦╦═╦╦═╗╔════
    * Origin: ═╩══╬╩═╩╩═╬╬═ (2:5020/9696.128)
  • From Richard Menedetter@2:310/31 to Alexander N. Skovpen on Thu Apr 4 12:18:32 2019
    Hi Alexander!

    04 Apr 2019 12:16, from Alexander N. Skovpen -> Richard Menedetter:

    I just wanted to display a message and got this message
    "wrong message signature"
    The message opened just fine in Golded.
    No idea what the problem was with GoatEd.
    in golded press alt-i on this message. maybe corrupted base.
    sqpack or hptfix to recover.

    I do not think that this message is corrupted.
    It displays fine. Here is the dump from golded.
    I can send you the JAM files as well if needed.


    ==== Begin "goated.txt" ====
    Hexdump of JAM message header, subfields and text ------------------------------------------------------------------------------

    Msgbase : /home/fido/msgbasedir/fidonews
    Signature : JAM
    Revision : 1
    ReservedWord : 0
    SubfieldLen : 590
    TimesRead : 1
    MSGIDcrc : 2F8793CDh
    REPLYcrc : 55BD5866h
    ReplyTo : 289
    Reply1st : 328
    ReplyNext : 332
    DateWritten : 2019-03-10 21:15:00 (5C857E54h)
    DateReceived : 1970-01-01 00:00:00 (00000000h)
    DateProcessed : 2019-03-11 03:00:24 (5C85CF48h)
    MessageNumber : 322
    Attribute : 02000000h (00000010000000000000000000000000b)
    Attribute2 : 00000000h (00000000000000000000000000000000b)
    Offset : 456050
    TxtLen : 2440
    PasswordCRC : FFFFFFFFh
    Cost : 0

    Index Record:

    UserCrc : F106029Eh
    HeaderOffset : 0002B639h (177721)

    Lastread Record:

    Index : 0
    UserCrc : 401684AFh
    UserId : 401684AFh
    Lastread : 322
    Highread : 326

    Base Header:

    DateCreated : 2019-04-03 23:57:24 (5CA54864h)
    ModCounter : 23
    ActiveMsgs : 1326
    PasswordCRC : FFFFFFFFh
    BaseMsgNum : 1
    HighWaterMark : 0

    Subfields:

    0000 02 00 00 00 0A 00 00 00 6D 61 72 6B 20 6C 65 77 ........mark lew 0010 69 73 03 00 00 00 0C 00 00 00 42 6A 94 72 6E 20 is........Bj.rn
    0020 46 65 6C 74 65 6E 06 00 00 00 24 00 00 00 54 72 Felten....$...Tr 0030 79 69 6E 67 20 74 6F 20 63 6F 6E 6E 65 63 74 20 ying to connect
    0040 74 6F 20 74 68 65 20 42 42 53 20 6E 65 74 77 6F to the BBS netwo 0050 72 6B 01 00 00 00 0C 00 00 00 31 3A 33 36 33 34 rk........1:3634 0060 2F 31 32 2E 37 33 05 00 00 00 10 00 00 00 32 3A /12.73........2: 0070 32 30 33 2F 32 20 35 63 38 35 35 62 39 61 04 00 203/2 5c855b9a.. 0080 00 00 15 00 00 00 31 3A 33 36 33 34 2F 31 32 2E ......1:3634/12. 0090 37 33 20 35 63 38 35 62 38 34 31 07 00 00 00 17 73 5c85b841..... 00A0 00 00 00 47 45 44 2B 4C 4E 58 20 31 2E 31 2E 35 ...GED+LNX 1.1.5 00B0 2D 62 32 30 31 38 30 37 30 37 D0 07 00 00 0D 00 -b20180707..... 00C0 00 00 43 48 52 53 3A 20 43 50 34 33 37 20 32 D4 ..CHRS: CP437 2 00D0 07 00 00 05 00 00 00 2D 30 34 30 30 D0 07 00 00 .......-0400... 00E0 1F 00 00 00 54 49 44 3A 20 68 70 74 2F 6C 6E 78 ....TID: hpt/lnx 00F0 20 31 2E 39 2E 30 2D 63 75 72 20 30 37 2D 30 39 1.9.0-cur 07-09 0100 2D 31 35 D1 07 00 00 43 00 00 00 31 2F 31 32 30 -15...C...1/120 0110 20 31 38 2F 30 20 31 30 33 2F 37 30 35 20 31 31 18/0 103/705 11 0120 36 2F 31 31 36 20 31 32 33 2F 30 20 32 35 20 35 6/116 123/0 25 5 0130 30 20 31 31 35 20 31 35 30 20 37 35 35 20 31 33 0 115 150 755 13 0140 35 2F 33 30 30 20 31 35 33 2F 37 37 31 35 D1 07 5/300 153/7715. 0150 00 00 3E 00 00 00 31 35 34 2F 31 30 20 32 30 33 ..>...154/10 203 0160 2F 30 20 32 32 31 2F 30 20 36 20 32 32 39 2F 34 /0 221/0 6 229/4 0170 32 36 20 32 34 30 2F 35 38 33 32 20 32 36 31 2F 26 240/5832 261/ 0180 33 38 20 32 38 30 2F 34 36 34 20 35 30 30 33 20 38 280/464 5003
    0190 35 35 35 35 D1 07 00 00 3B 00 00 00 32 39 32 2F 5555...;...292/ 01A0 36 32 34 20 38 35 34 20 33 31 30 2F 33 31 20 33 624 854 310/31 3 01B0 39 36 2F 34 35 20 34 32 33 2F 31 32 30 20 36 34 96/45 423/120 64 01C0 30 2F 33 30 35 20 31 33 32 31 20 31 33 38 34 20 0/305 1321 1384
    01D0 37 31 32 2F 38 34 38 D1 07 00 00 3B 00 00 00 37 712/848...;...7 01E0 37 30 2F 31 20 32 34 35 32 2F 32 35 30 20 33 36 70/1 2452/250 36 01F0 33 34 2F 30 20 31 32 20 31 35 20 32 37 20 35 30 34/0 12 15 27 50 0200 20 31 31 39 20 35 30 31 39 2F 34 30 20 35 30 32 119 5019/40 502 0210 30 2F 35 34 35 20 31 30 34 32 D1 07 00 00 07 00 0/545 1042..... 0220 00 00 35 30 35 33 2F 35 38 D2 07 00 00 1D 00 00 ..5053/58...... 0230 00 33 36 33 34 2F 31 32 20 36 34 30 2F 31 33 38 .3634/12 640/138 0240 34 20 32 38 30 2F 35 35 35 35 20 34 36 34 00 00 4 280/5555 464..

    00002 [ 10]: "mark lewis"
    00003 [ 12]: "Bj.rn Felten"
    00006 [ 36]: "Trying to connect to the BBS network"
    00001 [ 12]: "1:3634/12.73"
    00005 [ 16]: "2:203/2 5c855b9a"
    00004 [ 21]: "1:3634/12.73 5c85b841"
    00007 [ 23]: "GED+LNX 1.1.5-b20180707"
    02000 [ 13]: "CHRS: CP437 2"
    02004 [ 5]: "-0400"
    02000 [ 31]: "TID: hpt/lnx 1.9.0-cur 07-09-15"
    02001 [ 67]: "1/120 18/0 103/705 116/116 123/0 25 50 115 150 755 135/300 1" 02001 [ 62]: "154/10 203/0 221/0 6 229/426 240/5832 261/38 280/464 5003 55" 02001 [ 59]: "292/624 854 310/31 396/45 423/120 640/305 1321 1384 712/848" 02001 [ 59]: "770/1 2452/250 3634/0 12 15 27 50 119 5019/40 5020/545 1042" 02001 [ 7]: "5053/58"
    02002 [ 29]: "3634/12 640/1384 280/5555 464"

    Hexdump of message header:

    0000 4A 41 4D 00 01 00 00 00 4E 02 00 00 01 00 00 00 JAM.....N....... 0010 CD 93 87 2F 66 58 BD 55 21 01 00 00 48 01 00 00 ../fXU!...H... 0020 4C 01 00 00 54 7E 85 5C 00 00 00 00 48 CF 85 5C L...T~.\....H.\ 0030 42 01 00 00 00 00 00 02 00 00 00 00 72 F5 06 00 B...........r.. 0040 88 09 00 00 FF FF FF FF 00 00 00 00 00 00 00 00 ............

    Hexdump of message text:

    0000 0D 20 4F 6E 20 32 30 31 39 20 4D 61 72 20 31 30 . On 2019 Mar 10 0010 20 31 39 3A 34 36 3A 35 32 2C 20 79 6F 75 20 77 19:46:52, you w 0020 72 6F 74 65 20 74 6F 20 6D 65 3A 0D 0D 20 6D 6C rote to me:.. ml 0030 3E 3E 20 79 65 73 2C 20 72 65 61 6C 6C 79 2E 2E >> yes, really.. 0040 2E 0D 0D 20 42 46 3E 20 20 20 20 53 6F 2C 20 77 ... BF> So, w 0050 68 61 74 20 68 61 70 70 65 6E 73 20 77 68 65 6E hat happens when 0060 20 79 6F 75 20 63 6C 69 63 6B 20 6F 6E 20 65 2E you click on e. 0070 67 2E 20 66 69 64 6F 6E 65 77 73 2E 65 75 3F 0D g. fidonews.eu?. 0080 0D 63 6C 69 63 6B 20 69 74 20 77 68 65 72 65 3F .click it where? 0090 20 68 6F 77 20 63 61 6E 20 79 6F 75 20 63 6C 69 how can you cli 00A0 63 6B 20 6F 6E 20 73 6F 6D 65 74 68 69 6E 67 20 ck on something
    00B0 69 6E 20 61 6E 20 38 30 78 32 35 20 41 53 43 49 in an 80x25 ASCI 00C0 49 20 74 65 72 6D 69 6E 61 6C 3F 3F 3F 0D 0D 20 I terminal???..
    00D0 42 46 3E 20 57 68 61 74 20 69 66 20 79 6F 75 20 BF> What if you
    00E0 63 68 6F 6F 73 65 20 22 43 68 65 63 6B 20 69 74 choose "Check it 00F0 20 6F 75 74 20 61 6E 6F 6E 79 6D 6F 75 73 6C 79 out anonymously 0100 22 3F 20 57 6F 75 6C 64 6E 27 74 20 74 68 61 74 "? Wouldn't that 0110 20 62 65 20 79 6F 75 72 0D 20 42 46 3E 20 76 65 be your. BF> ve 0120 72 79 20 66 69 72 73 74 20 63 68 6F 69 63 65 20 ry first choice
    0130 69 66 20 79 6F 75 20 77 65 72 65 20 6E 65 77 20 if you were new
    0140 74 6F 20 6F 75 72 20 6E 65 74 77 6F 72 6B 3F 0D to our network?. 0150 0D 6E 6F 70 65 20 27 63 61 75 73 65 20 69 74 20 .nope 'cause it
    0160 77 6F 75 6C 64 6E 27 74 20 62 65 20 62 65 69 6E wouldn't be bein 0170 67 20 73 65 65 6E 20 6C 69 6B 65 20 79 6F 75 20 g seen like you
    0180 61 72 65 20 61 73 73 75 6D 69 6E 67 20 69 74 20 are assuming it
    0190 77 6F 75 6C 64 20 62 65 2E 2E 2E 0D 0D 20 42 46 would be..... BF 01A0 3E 20 20 20 20 57 68 65 72 65 27 73 20 74 68 65 > Where's the 01B0 20 63 61 74 63 68 2D 32 32 20 74 68 65 72 65 3F catch-22 there? 01C0 0D 0D 63 6F 6D 70 6C 65 74 65 6C 79 20 66 6F 72 ..completely for 01D0 67 65 74 20 74 68 61 74 20 79 6F 75 20 6B 6E 6F get that you kno 01E0 77 20 61 6E 79 74 68 69 6E 67 20 61 74 20 61 6C w anything at al 01F0 6C 20 61 62 6F 75 74 20 66 69 64 6F 6E 65 74 2E l about fidonet. 0200 2E 2E 20 79 6F 75 20 64 6F 6E 27 74 20 68 61 76 .. you don't hav 0210 65 20 61 20 63 6C 75 65 20 77 68 61 74 20 65 63 e a clue what ec 0220 68 6F 6D 61 69 6C 20 6F 72 20 6E 65 74 6D 61 69 homail or netmai 0230 6C 20 69 73 2E 2E 2E 20 6E 6F 20 69 64 65 61 20 l is... no idea
    0240 77 68 61 74 20 61 20 22 6D 61 69 6C 65 72 22 20 what a "mailer"
    0250 6F 72 20 22 74 6F 73 73 65 72 22 20 61 72 65 2E or "tosser" are. 0260 2E 2E 20 6E 6F 77 20 74 72 79 20 74 6F 20 66 69 .. now try to fi 0270 67 75 72 65 20 6F 75 74 20 68 6F 77 20 74 6F 20 gure out how to
    0280 6A 6F 69 6E 20 66 69 64 6F 6E 65 74 2E 2E 2E 0D join fidonet.... 0290 0D 20 42 46 3E 20 49 74 20 73 65 65 6D 73 20 6C . BF> It seems l 02A0 69 6B 65 20 61 6C 6D 6F 73 74 20 61 6C 6C 20 6F ike almost all o 02B0 66 20 74 68 65 20 72 65 6D 61 69 6E 69 6E 67 20 f the remaining
    02C0 66 69 64 6F 6E 65 74 20 73 79 73 6F 70 73 2C 20 fidonet sysops,
    02D0 39 35 25 20 6F 72 20 73 6F 2C 0D 20 42 46 3E 20 95% or so,. BF>
    02E0 73 65 65 6D 20 74 6F 20 62 65 20 77 68 61 74 20 seem to be what
    02F0 66 6F 72 6D 65 72 6C 79 20 77 61 73 20 64 65 66 formerly was def 0300 69 6E 65 64 20 61 73 20 70 6F 69 6E 74 2D 6F 70 ined as point-op 0310 73 2C 20 68 61 76 65 20 66 6F 72 67 6F 74 74 65 s, have forgotte 0320 6E 20 74 68 61 74 0D 20 42 46 3E 20 66 69 64 6F n that. BF> fido 0330 6E 65 74 20 77 61 73 20 6F 72 69 67 69 6E 61 6C net was original 0340 6C 79 20 61 20 42 42 53 2D 6E 65 74 77 6F 72 6B ly a BBS-network 0350 3A 0D 0D 79 6F 75 20 61 72 65 20 69 62 63 6C 75 :..you are ibclu 0360 64 69 6E 67 20 79 6F 75 72 73 65 6C 66 20 69 6E ding yourself in 0370 20 74 68 61 74 20 63 6F 75 6E 74 2C 20 72 69 67 that count, rig 0380 68 74 3F 20 65 73 70 65 63 69 61 6C 6C 79 20 77 ht? especially w 0390 69 74 68 20 79 6F 75 72 20 22 63 6C 69 63 6B 20 ith your "click
    03A0 74 68 69 73 22 20 61 6E 64 20 22 63 6C 69 63 6B this" and "click 03B0 20 74 68 61 74 22 20 73 74 61 74 65 6D 65 6E 74 that" statement 03C0 73 2E 2E 2E 20 74 68 65 72 65 20 61 69 6E 27 74 s... there ain't 03D0 20 6E 6F 20 63 6C 69 63 6B 69 6E 67 20 61 6E 79 no clicking any 03E0 74 68 69 6E 67 20 69 6E 20 66 69 64 6F 6E 65 74 thing in fidonet 03F0 2C 20 6D 61 6E 21 20 68 61 68 61 68 61 68 61 68 , man! hahahahah 0400 61 2E 2E 2E 0D 0D 20 42 46 3E 20 20 20 20 22 54 a..... BF> "T 0410 68 69 73 20 64 6F 63 75 6D 65 6E 74 20 65 73 74 his document est 0420 61 62 6C 69 73 68 65 73 20 74 68 65 20 70 6F 6C ablishes the pol 0430 69 63 79 20 66 6F 72 20 73 79 73 6F 70 73 20 77 icy for sysops w 0440 68 6F 20 61 72 65 20 6D 65 6D 62 65 72 73 20 6F ho are members o 0450 66 0D 20 42 46 3E 20 20 20 20 20 74 68 65 20 46 f. BF> the F 0460 69 64 6F 4E 65 74 20 6F 72 67 61 6E 69 7A 61 74 idoNet organizat 0470 69 6F 6E 20 6F 66 20 65 6C 65 63 74 72 6F 6E 69 ion of electroni 0480 63 20 62 75 6C 6C 65 74 69 6E 20 62 6F 61 72 64 c bulletin board 0490 20 73 79 73 74 65 6D 73 2E 22 0D 0D 20 42 46 3E systems.".. BF> 04A0 20 20 20 20 54 68 69 73 20 69 73 20 74 68 65 20 This is the
    04B0 76 65 72 79 20 66 69 72 73 74 20 73 65 6E 74 65 very first sente 04C0 6E 63 65 20 69 6E 20 6F 75 72 20 70 6F 6C 69 63 nce in our polic 04D0 79 20 77 68 65 6E 20 73 63 61 6C 65 64 20 61 6C y when scaled al 04E0 6C 20 74 68 65 20 61 64 6D 69 6E 0D 20 42 46 3E l the admin. BF> 04F0 20 69 6E 63 65 70 74 69 6F 6E 73 20 61 72 65 20 inceptions are
    0500 6F 66 66 2E 20 41 6E 20 22 45 6C 65 63 74 72 6F off. An "Electro 0510 6E 69 63 20 62 75 6C 6C 65 74 69 6E 20 62 6F 61 nic bulletin boa 0520 72 64 20 73 79 73 74 65 6D 22 20 77 61 73 2C 20 rd system" was,
    0530 61 6E 64 20 6F 66 0D 20 42 46 3E 20 63 6F 75 72 and of. BF> cour 0540 73 65 20 73 74 69 6C 6C 20 69 73 2C 20 74 68 65 se still is, the 0550 20 73 61 6D 65 20 61 73 20 61 20 42 42 53 2E 20 same as a BBS.
    0560 49 66 20 79 6F 75 20 64 6F 6E 27 74 20 72 75 6E If you don't run 0570 20 61 20 42 42 53 2C 20 79 6F 75 20 61 72 65 20 a BBS, you are
    0580 6E 6F 74 0D 20 42 46 3E 20 65 6E 74 69 74 6C 65 not. BF> entitle 0590 64 20 74 6F 20 62 65 20 6E 6F 64 65 6C 69 73 74 d to be nodelist 05A0 65 64 20 69 6E 20 74 68 65 20 42 42 53 2D 6E 65 ed in the BBS-ne 05B0 74 77 6F 72 6B 20 6F 66 20 66 69 64 6F 6E 65 74 twork of fidonet 05C0 2E 0D 0D 20 42 46 3E 20 20 20 20 53 6F 6D 65 20 ... BF> Some
    05D0 6F 66 20 75 73 20 73 74 69 6C 6C 20 74 61 6B 65 of us still take 05E0 20 74 68 69 73 20 73 65 72 69 6F 75 73 6C 79 2C this seriously, 05F0 0D 0D 72 65 61 6C 6C 79 3F 20 79 65 74 20 79 6F ..really? yet yo 0600 75 20 22 63 6C 69 63 6B 20 74 68 69 73 22 20 61 u "click this" a 0610 6E 64 20 22 63 6C 69 63 6B 20 74 68 61 74 22 2E nd "click that". 0620 2E 2E 20 66 69 64 6F 6E 65 74 20 64 6F 65 73 6E .. fidonet doesn 0630 27 74 20 64 6F 20 22 63 6C 69 63 6B 73 22 20 61 't do "clicks" a 0640 6E 64 20 22 6C 69 6E 6B 73 22 2E 2E 2E 20 66 69 nd "links"... fi 0650 64 6F 6E 65 74 20 69 73 20 70 75 72 65 20 41 53 donet is pure AS 0660 43 49 49 20 74 65 78 74 2E 2E 2E 20 6E 6F 20 6C CII text... no l 0670 69 6E 6B 73 2C 20 61 6E 69 6D 61 74 69 6F 6E 73 inks, animations 0680 2C 20 6F 72 20 70 72 65 74 74 79 20 70 69 63 74 , or pretty pict 0690 75 72 65 73 2E 2E 2E 0D 0D 20 42 46 3E 20 61 20 ures..... BF> a
    06A0 76 61 73 74 20 6D 61 6A 6F 72 69 74 79 20 64 6F vast majority do 06B0 6E 27 74 20 67 69 76 65 20 61 20 73 68 69 74 2E n't give a shit. 06C0 20 41 6E 64 20 77 65 20 63 61 6E 20 73 65 65 20 And we can see
    06D0 74 68 65 20 72 65 73 75 6C 74 2C 20 62 75 74 20 the result, but
    06E0 74 68 65 0D 20 42 46 3E 20 6D 61 6A 6F 72 69 74 the. BF> majorit 06F0 79 20 70 72 65 66 65 72 20 74 6F 20 70 75 74 20 y prefer to put
    0700 61 20 62 6C 69 6E 64 20 65 79 65 20 77 69 74 68 a blind eye with 0710 6F 75 74 20 72 65 67 61 72 64 69 6E 67 20 74 68 out regarding th 0720 65 20 6E 65 67 61 74 69 76 65 0D 20 42 46 3E 20 e negative. BF>
    0730 69 6D 70 61 63 74 20 69 74 20 68 61 73 20 6F 6E impact it has on 0740 20 6F 75 72 20 6E 65 74 77 6F 72 6B 2E 0D 0D 68 our network...h 0750 75 6D 6D 6D 2E 2E 2E 0D 0D 20 42 46 3E 20 57 69 ummm..... BF> Wi 0760 74 68 20 6F 6E 6C 79 20 61 6C 6C 20 74 68 65 20 th only all the
    0770 77 6F 72 6B 69 6E 67 20 42 42 53 73 20 6E 6F 64 working BBSs nod 0780 65 6C 69 73 74 65 64 2C 20 61 6E 64 20 61 6C 6C elisted, and all 0790 20 74 68 65 20 6F 74 68 65 72 2C 0D 20 42 46 3E the other,. BF> 07A0 20 67 6C 6F 72 69 66 69 65 64 20 70 6F 69 6E 74 glorified point 07B0 20 73 79 73 74 65 6D 73 20 63 6F 6E 6E 65 63 74 systems connect 07C0 65 64 20 74 6F 20 74 68 6F 73 65 20 66 65 77 20 ed to those few
    07D0 28 35 30 20 6F 72 20 73 6F 3F 29 2C 20 69 74 20 (50 or so?), it
    07E0 77 6F 75 6C 64 0D 20 42 46 3E 20 62 65 20 61 20 would. BF> be a
    07F0 70 69 65 63 65 20 6F 66 20 63 61 6B 65 20 74 6F piece of cake to 0800 20 63 72 65 61 74 65 20 61 20 74 72 75 65 2C 20 create a true,
    0810 63 6F 6D 70 6C 65 74 65 20 6D 65 73 68 20 6F 66 complete mesh of 0820 20 66 69 64 6F 6E 65 74 20 6E 6F 64 65 73 2E 0D fidonet nodes.. 0830 0D 72 65 61 6C 6C 79 3F 3F 3F 20 79 6F 75 20 74 .really??? you t 0840 61 6B 65 20 74 68 69 73 20 61 73 20 61 6E 20 6F ake this as an o 0850 70 70 6F 72 74 75 6E 69 74 79 20 74 6F 20 77 61 pportunity to wa 0860 76 65 20 74 68 65 20 66 69 64 6F 77 65 62 20 64 ve the fidoweb d 0870 69 63 6B 20 69 6E 20 66 6F 6C 6B 73 27 20 66 61 ick in folks' fa 0880 63 65 73 20 61 67 61 69 6E 3F 3F 3F 20 64 65 69 ces again??? dei 0890 74 79 2C 20 79 6F 75 20 74 61 6B 65 20 74 68 65 ty, you take the 08A0 20 63 61 6B 65 21 0D 0D 29 5C 2F 28 61 72 6B 0D cake!..)\/(ark. 08B0 0D 41 6C 77 61 79 73 20 4D 6F 75 6E 74 20 61 20 .Always Mount a
    08C0 53 63 72 61 74 63 68 20 4D 6F 6E 6B 65 79 0D 44 Scratch Monkey.D 08D0 6F 20 79 6F 75 20 6D 61 6E 61 67 65 20 79 6F 75 o you manage you 08E0 72 20 6F 77 6E 20 73 65 72 76 65 72 73 3F 20 49 r own servers? I 08F0 66 20 79 6F 75 20 61 72 65 20 6E 6F 74 20 72 75 f you are not ru 0900 6E 6E 69 6E 67 20 61 6E 20 49 44 53 2F 49 50 53 nning an IDS/IPS 0910 20 79 65 72 20 64 6F 69 6E 27 20 69 74 20 77 72 yer doin' it wr 0920 6F 6E 67 2E 2E 2E 0D 2E 2E 2E 20 48 6F 77 20 6D ong....... How m 0930 61 6E 79 20 72 6F 61 64 73 20 6D 75 73 74 20 61 any roads must a 0940 20 6D 61 6E 20 74 72 61 76 65 6C 20 62 65 66 6F man travel befo 0950 72 65 20 68 65 20 61 64 6D 69 74 73 20 68 65 20 re he admits he
    0960 69 73 20 6C 6F 73 74 2E 0D 2D 2D 2D 0D 20 2A 20 is lost..---. *
    0970 4F 72 69 67 69 6E 3A 20 20 28 31 3A 33 36 33 34 Origin: (1:3634 0980 2F 31 32 2E 37 33 29 0D 00 00 00 00 00 00 00 00 /12.73).........

    ==== End "goated.txt" ====

    CU, Ricsi

    ... If the people have no bread, let them eat cake. - Marie Antoinette
    --- GoldED+/LNX
    * Origin: All words are pegs on which to hang ideas. (2:310/31)
  • From Michiel van der Vlist@2:280/5555 to Richard Menedetter on Thu Apr 4 11:56:25 2019
    Hello Richard Menedetter!

    04 Apr 19 09:49:30, Richard Menedetter wrote to Alexander N. Skovpen:

    Also I have found this:
    Subj : Trying to connect to the BBS network Corrupted

    Behind the subject line GoatEd wrote Corrupted in bright red. (but it displayed the message correctly.)

    I have seen the same.

    My conjecture is that it occurs with messages:

    o having "Björn Felten" in the To field.

    o having a non FTS-9 conform MSGID.


    Michiel



    --- goAtEd-windows/386 1.0.4-152-634cebd3
    * Origin: (2:280/5555)
  • From Richard Menedetter@2:310/31 to Michiel van der Vlist on Thu Apr 4 14:56:28 2019
    Hi Michiel!

    04 Apr 2019 11:56, from Michiel van der Vlist -> Richard Menedetter:

    Corrupted

    I have seen the same.
    My conjecture is that it occurs with messages:
    o having "Bj|rn Felten" in the To field.
    o having a non FTS-9 conform MSGID.

    Sounds very likely.
    That will be it.

    IMO this "corruption" should simply be ignored.

    Michiel regarding Q ... that does not change more or less than for example ALT-Q.
    So that is not really an argument for not using q.

    CU, Ricsi

    ... A rose by any other name would be "deadly thorny assault vegetation".
    --- GoldED+/LNX
    * Origin: A rumor doesn't gain credence until officially denied. (2:310/31)
  • From Michiel van der Vlist@2:280/5555 to Richard Menedetter on Thu Apr 4 13:53:28 2019
    Hello Richard Menedetter!

    04 Apr 19 14:56:28, Richard Menedetter wrote to Michiel van der Vlist:

    My conjecture is that it occurs with messages:
    o having "Bj|Ârn Felten" in the To field.
    o having a non FTS-9 conform MSGID.

    Sounds very likely.
    That will be it.

    IMO this "corruption" should simply be ignored.

    I have yet to see the penalty for ignoring it. ;)


    Michiel


    --- goAtEd-windows/386 1.0.4-152-634cebd3
    * Origin: (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Richard Menedetter on Thu Apr 4 14:11:42 2019
    Hello Richard Menedetter!

    04 Apr 19 14:56:28, Richard Menedetter wrote to Michiel van der Vlist:

    Michiel regarding Q ... that does not change more or less than for example ALT-Q.
    So that is not really an argument for not using q.

    But it is...

    1) The Alt codes do not work in the Win32 version of goated, only the control codes work.

    2) The codes generated by Alt q and control q are independant of the keyboard setting. With the keyboard in US ASCII the q key generates the ASCII code for the letter q. With the keyboard in Cyillic mode it generates the CP866 or UTF-8 code for the Russian letter й. I tried it in Golded. Alt q, control q and q all do the same in "ASCII" modes. In Cyrillic mode Alt q and control q work. Pressing the q key does nothing.

    Same in goated with < and > for first and last message. It does not work with the keyboard in Cyrillic mode. In Cyrillic mode they are б and ю.

    I suspect you do not have other keyboard modes than German installed...


    Michiel

    --- goAtEd-windows/386 1.0.4-152-634cebd3
    * Origin: (2:280/5555)
  • From mark lewis@1:3634/12.73 to Richard Menedetter on Thu Apr 4 12:43:34 2019
    On 2019 Apr 04 09:49:30, you wrote to Alexander N. Skovpen:

    in goated can do only critical bugfixes.

    I have found that messages that I read in GoatEd are shown as unread
    in Golded.

    JAM message base format or something else? it could be that the two are using different lastread pointer records...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... We are going to have peace even if we have to fight for it.
    ---
    * Origin: (1:3634/12.73)
  • From Richard Menedetter@2:310/31 to mark lewis on Thu Apr 4 20:19:54 2019
    Hi mark!

    04 Apr 2019 12:43, from mark lewis -> Richard Menedetter:

    I have found that messages that I read in GoatEd are shown as
    unread in Golded.
    JAM message base format or something else? it could be that the two
    are using different lastread pointer records...

    Yes, JAM.
    It is a single user system.
    I have not configured anything special in golded or goated about using another lastread pointer.
    Do others see the same behaviour as I with goated?

    CU, Ricsi

    ... Paranoia: Fear of white designer jackets that close from behind.
    --- GoldED+/LNX
    * Origin: "New and improved" = More expensive. (2:310/31)
  • From Alexander N. Skovpen@2:5020/9696.128 to Richard Menedetter on Thu Apr 4 22:08:08 2019
    Hello Richard Menedetter!

    04 Apr 19 20:19:54, Richard Menedetter wrote to mark lewis:

    Yes, JAM.
    It is a single user system.
    I have not configured anything special in golded or goated about using another lastread pointer.
    Do others see the same behaviour as I with goated?
    jam db use username as lastread key. if usernames same - lastread pointer is synced.

    Alexander


    --- ════════╦╦═╦╦═╗╔════
    * Origin: ═╩══╬╩═╩╩═╬╬═ (2:5020/9696.128)
  • From Richard Menedetter@2:310/31 to Alexander N. Skovpen on Thu Apr 4 22:22:24 2019
    Hi Alexander!

    04 Apr 2019 22:08, from Alexander N. Skovpen -> Richard Menedetter:

    Yes, JAM.
    It is a single user system.
    I have not configured anything special in golded or goated about
    using another lastread pointer. Do others see the same behaviour
    as I with goated?
    jam db use username as lastread key. if usernames same - lastread
    pointer is synced.

    I have in Golded:
    USERNAME Richard Menedetter

    In Goated:
    username: Richard Menedetter

    When I read a message in goated, it is still marked unread in golded.

    What am I doing wrong?

    CU, Ricsi

    ... The louder he talked of his honor, the faster we counted our spoons.
    --- GoldED+/LNX
    * Origin: SIN OF OMISSION: Any Sin that you forgot to commit. (2:310/31)
  • From mark lewis@1:3634/12.73 to Richard Menedetter on Thu Apr 4 15:59:04 2019
    On 2019 Apr 04 20:19:54, you wrote to me:

    I have found that messages that I read in GoatEd are shown as
    unread in Golded.
    JAM message base format or something else? it could be that the two
    are using different lastread pointer records...

    Yes, JAM.

    ok...

    It is a single user system.

    ok... that makes it easier...

    I have not configured anything special in golded or goated about using another lastread pointer.

    you don't have to... generally those options are provided so you can force separate tools to use the same LR pointer record...

    using a hex editor, look at the JLR file for the area in question... the jlr file should be a multiple of 16 because there are 16 bytes allocated to the lastread records for each user...

    looking internally with a hex editor, you may see two sets of identical fields... the first field (four bytes) should be the CRC32 of the lowercase user name... the second field (four bytes) should be the user number... in some
    JAM capable software, they use the same value in both fields...

    the other two fields are the lastread and highread fields... they may be the same if the user's lastread is the highest they have read in the area otherwise
    they should be different with the second one being a higher decimal value... some software keeps them both the same which rather negates the feature of having a highread value...

    anyway, just thought i'd provide that info in case it may be helpful... if one package uses a different record or uses the lastread and highread values differently, you may see some oddities when switching between the two packages...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Hydrogen bombs are great party gags.
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Alexander N. Skovpen on Thu Apr 4 16:37:54 2019
    On 2019 Apr 04 22:08:08, you wrote to Richard Menedetter:

    Yes, JAM.
    It is a single user system.
    I have not configured anything special in golded or goated about using
    another lastread pointer. Do others see the same behaviour as I with
    goated?

    jam db use username as lastread key.

    lowercase username, right?

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... To boldly go where no sane person has any business.
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Richard Menedetter on Thu Apr 4 16:38:50 2019
    On 2019 Apr 04 22:22:24, you wrote to Alexander N. Skovpen:

    I have in Golded:
    USERNAME Richard Menedetter

    In Goated:
    username: Richard Menedetter

    When I read a message in goated, it is still marked unread in golded.

    do you mean a message addressed to your name?? netmail or echomail or both?

    What am I doing wrong?

    maybe nothing if the same attributes are not used due to a bug... this would be
    different than lastread/highread since it now seems like you are talking about
    the received bit on messages addressed to your name...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... Levi strauss: Waltz music performed while wearing jeans.
    ---
    * Origin: (1:3634/12.73)
  • From Richard Menedetter@2:310/31 to mark lewis on Thu Apr 4 23:22:58 2019
    Hi mark!

    04 Apr 2019 15:59, from mark lewis -> Richard Menedetter:

    using a hex editor, look at the JLR file for the area in question...
    the jlr file should be a multiple of 16 because there are 16 bytes allocated to the lastread records for each user...

    There is one user.
    The file is 16 byte long and looks like this:

    fido@vserv:~/msgbasedir$ hexdump fidonews.jlr
    0000000 84af 4016 84af 4016 0148 0000 0148 0000
    0000010

    CU, Ricsi

    ... We demand rigidly defined areas of doubt and uncertainty! -Douglas Adams --- GoldED+/LNX
    * Origin: Copy from another:plagiarism. Copy from many:research. (2:310/31)
  • From Richard Menedetter@2:310/31 to mark lewis on Thu Apr 4 23:24:22 2019
    Hi mark!

    04 Apr 2019 16:38, from mark lewis -> Richard Menedetter:

    do you mean a message addressed to your name?? netmail or echomail or both?

    I have seen it with echomail not addressed to me. (did not check for the rest) Golded shows unread messages in another color.
    When I read a message in golded it is no longer marked as unread.
    If I read a message in goated, and go to golded, it is still marked as unread.

    What am I doing wrong?
    maybe nothing if the same attributes are not used due to a bug... this would be different than lastread/highread since it now seems like you
    are talking about the received bit on messages addressed to your
    name...

    Indeed ... the received bit of the JAM messagebase.

    CU, Ricsi

    ... Few milkmen are married as they've seen women too early in the morning.
    --- GoldED+/LNX
    * Origin: Now touch these wires to your tongue! (2:310/31)
  • From mark lewis@1:3634/12.73 to Richard Menedetter on Thu Apr 4 19:32:14 2019

    On 2019 Apr 04 23:22:58, you wrote to me:

    using a hex editor, look at the JLR file for the area in question...
    the jlr file should be a multiple of 16 because there are 16 bytes
    allocated to the lastread records for each user...

    There is one user. The file is 16 byte long and looks like this:

    fido@vserv:~/msgbasedir$ hexdump fidonews.jlr
    0000000 84af 4016 84af 4016

    those two are the proper CRC32 values for your name in lowercase...

    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...

    )\/(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 one fool can do, another can. -Ancient Simian Proverb
    ---
    * Origin: (1:3634/12.73)
  • From Alexander N. Skovpen@2:5020/9696.128 to mark lewis on Fri Apr 5 09:17:08 2019
    Hello mark lewis!

    04 Apr 19 16:37:54, mark lewis wrote to Alexander N. Skovpen:

    Yes, JAM.
    It is a single user system.
    I have not configured anything special in golded or goated about using
    another lastread pointer. Do others see the same behaviour as I with
    goated?
    jam db use username as lastread key.
    lowercase username, right?
    crc function make it lowercase.

    Alexander


    --- ════════╦╦═╦╦═╗╔════
    * Origin: ═╩══╬╩═╩╩═╬╬═ (2:5020/9696.128)
  • From Richard Menedetter@2:310/31 to mark lewis on Fri Apr 5 12:46:20 2019
    Hi mark!

    04 Apr 2019 19:32, from mark lewis -> Richard Menedetter:

    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 ;)

    CU, Ricsi

    ... The louder he talked of his honor, the faster we counted our spoons.
    --- GoldED+/LNX
    * Origin: Never step in anything soft. (2:310/31)
  • 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)