BBS: TELESC.NET.BR Assunto: Re: htick "issue" De: Mike Powell Data: Tue, 28 Apr 2026 10:26:25 -0500 ----------------------------------------------------------- > 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) ----------------------------------------------------------- [Voltar]