BBS: TELESC.NET.BR
Assunto: Re: htick "issue"
De: Wilfred van Velzen
Data: Tue, 28 Apr 2026 11:35:19 +0200
-----------------------------------------------------------
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)
-----------------------------------------------------------
[Voltar]