@MSGID: 70.husky@1:2320/107 2e5607e7
@REPLY: 2:280/464 69f07f77
@TZUTC: -0500
@PID: Synchronet 3.21a-Linux master/123f2d28a Jul 12
2025 GCC 12.2.0
@TID: SBBSecho 3.28-Linux master/123f2d28a Jul 12
2025 GCC 12.2.0
@BBSID: CAPCITY2
@CHRS: ASCII 1
@FORMAT: flowed
>         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.

Thanks.  This is a better explanation than I could give.  Most BBS sofware
does this and depends on something like `crashmaint PACK` (or the husky
equivalent) to run later.

>             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? :-)

I wonder, then, if a utility like crashmaint would still be able to find
the message to remove it if it finds this "there is no corresponding message
header" flag in the index?

It doesn`t matter in my case, just a random trivial thought.  ;)

Mike

 * SLMR 2.1a * ...gnorw og... gnorw og... gnorw og nac gnihton
--- SBBSecho 3.28-Linux
 * Origin: Capitol City Online (1:2320/107)
SEEN-BY: 19/10 50/109 104/117 119 114/10 120/616
153/757 154/10 30 50 700
SEEN-BY: 218/840 220/20 90 221/1 6 360 226/18 20
44 50 280/464 301/1 335/364
SEEN-BY: 341/66 234 452/28 166 460/58 463/68
2320/105 106 107 304 3634/12
SEEN-BY: 5000/111 5010/352 5015/46 5020/715 828 846
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5053/51 5061/133 5075/128
5083/444 12320/7
@PATH: 2320/107 105 154/10 221/6 5020/1042 4441