MHonArc users,
I received a private message asking about mhonarc message numbers
and how they are used. Since I think what I have to say maybe of
interest to other users, I thought I would share with the list so
it will become part of the mhonarc archive so it can be referenced
and searched for those interested.
Here goes:
All messages that are added into an archive get assigned an integer
number. Numbering starts at zero. New messages get assigned the next
available number. Once a message has a number, it never changes for
that message.
If a message is deleted from an archive, the message number assigned to
it may, or may not, get reused. More likely, not. Mhonarc determines
the next available number by taking the largest assigned number and
adding 1 to it. Hence, if all message removals are on the lowest
numbered messages, those numbers are lost. If the removals are on the
largest messages(s), then those numbers may get resused. For example,
if the largets message number is 100, and I do:
mhonarc -rmm 100
then the next new message added will get assigned 100.
Message numbers get used in the HTML filenames of the converted messages
with the number portion at least 5 digits in length, padded with leading
zeros if necessary. The padding should not be of concern since
mhonarc hides that with resource variables (and in the -rmm option).
However, you may need to know about if you write any custom utilities
that process HTML message files.
BTW, one can predict what the next assigned message number will by
finding the largets number in use in a msg*.html filename and adding
one to it. This is basically what MHonArc does to determine the next
available number. Therefore, if you created a bogus file called
msg99999.html in an archive, MHonArc will use 100000 as the next
available number. For those familiar with MH mail user agent, MHonArc
determination of the next available number should not be foreign to you
(note: MHonArc starts number at 0 while MH starts at 1).
From a coding perspective, the function MHonArc uses to get the
next available number is getNewMsgNum(). In theory, this function
could be modified to try to reuse freed up numbers. However, this
could cause a performance hit and affect the uses of sorting indexes
by message number.
The message number is used when creating the unique key for each
message for all the has lookups done. However, from review of the
code, the message number portion of the key is never used when
determine the message number of message (the time portions of the key
does get used though). The %IndexNum is used for determing the message
number of a message. Therefore, it is programmically possible to
change the message number for a message w/o having to modify the
message key and worry about updating all the hashes with a new key.
However, one would still have to rename the message page filename and
update all links that used the old name. These items are the reason
that any renumbering functionality is low on my todo list. Plus,
such functionality does yet seem to be that important.
I do not know how useful this information is, or how clear it, but I
hope it useful to someone.
--ewh
