Nп/п : 55 из 100
 От   : Wilfred van Velzen                  2:280/464         28 апр 26 11:35:19
 К    : Nick Boel                                             28 апр 26 12:43:02
 Тема : Re: htick "issue"
----------------------------------------------------------------------------------
                                                                                 
@MSGID: 2:280/464 69f07f77
@REPLY: 1:154/700 69f001d5
@TID: FMail-lnx64 2.3.3.1-B20260417
@RFC-X-No-Archive: Yes
@TZUTC: 0200
@CHRS: CP850 2
@PID: GED+LNX 1.1.5-b20240604
Hi Nick,

On 2026-04-27 19:37:28, you wrote to Mike Powell:

 NB> What was being used to delete it from the JAM base?

  NB> In my case, with Golded+, I have to use the config option
"JAMHARDDELETE YES".
 NB> So there must be some difference between just deleting a message (maybe it
 NB> stays in the JAM base, but is not visible to anyone?), and this hard delete
 NB> option (which I assume removes it from the JAM base, entirely).

From goldref.txt:

        JAMHARDDELETE   (no)

            The default setting makes GoldED conform to the JAMAPI specs when
            deleting msgs in JAM msgbases. This means that deleted msgs are
            only marked as such in the message header, not in the index. As a
            result, GoldED will find and display the deleted msgs until you
            run a message pack utility to physically remove the deleted msgs.

            If JAMHARDDELETE is set to Yes, GoldED will zap the reference to
            the message in the index when deleting msgs. This way the deleted
            msgs will not show up again later. The drawback of this approach
            is that it is hard to undelete msgs, and may break other software
            which assume 100% to-the-letter conformance to the specs. Note
            however, that the hard-delete method is transparent to normal use
            of JAM msgbases. Probably the only software that might break are
            undelete utilities.

            For the techies and programmers, the hard-delete method is simply
            setting both UserCRC and HdrOffset in the index to 0xFFFFFFFF
            instead of only the UserCRC. According to the JAMAPI specs, a
            value of 0xFFFFFFFF in HdrOffset means that "there is no
            corresponding message header". Sounds remarkably like a deleted
            msg, right? :-)


Bye, Wilfred.

--- FMail-lnx64 2.3.3.1-B20260417
 * Origin: FMail development HQ (2:280/464)
SEEN-BY: 19/10 50/109 103/705 104/117 124/5016
153/757 154/10 30 203/0
SEEN-BY: 218/840 221/0 1 6 360 229/426 240/1120
5832 263/1 280/464 5003 5006
SEEN-BY: 292/854 8125 301/1 310/31 335/364 341/66
234 396/45 423/120 452/28
SEEN-BY: 452/166 460/58 256 1124 5858 463/68
633/280 712/848 770/1 5000/111
SEEN-BY: 5010/352 5015/46 5020/400 715 828 846 848
1042 4441 8912 12000
SEEN-BY: 5030/49 1081 5053/51 5054/30 5061/133
5075/128 5083/444
@PATH: 280/464 460/58 221/6 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх