I'm not sure if this is related to what Akos Csilling reported, since I
regenerate the entire MHonArc conversion of a mailing list folder nightly,
rather than adding only new messages:
I encountered the following problem with a multi-page index: when the total
number of messages is evenly divisible by the number of message-links per
index page, a last index page without *any* message links on it is created.
An example of this can be seen (for about another 14 hours, anyway, when
there will be more than exactly 3400 messages with 50 links per page ;-) at
URL:
http://www.washington.edu/imap/listarch/thrd69.html
If this is not the same bug -- has anyone else encountered this phenomenon?
------------------------------------------------------------
Stefan Kramer skramer(_at_)cac(_dot_)washington(_dot_)edu
Network Information Center http://www.washington.edu/nic/
Computing & Communications University of Washington
------------------------------------------------------------
On Thu, 6 Mar 1997, Earl Hood wrote:
# Date: Thu, 06 Mar 1997 15:33:08 -0800
# From: Earl Hood <ehood(_at_)hydra(_dot_)acs(_dot_)uci(_dot_)edu>
# To: Akos Csilling <Akos(_dot_)Csilling(_at_)cern(_dot_)ch>
# Cc: Mhonarc mailing list
<mhonarc(_at_)rosat(_dot_)mpe-garching(_dot_)mpg(_dot_)de>
# Subject: Re: Last index page
#
# > The problem is that while the number of pages steadily increases, only
# > the newest index files get updated, so as a result the link to the last
# > page is not correct on the first page(s).
#
# You found a bug. MHonArc tries to minimize file I/O by only updated
# index pages that need updating. The problem is that mhonarc does
# not check if the last page has changed (note, by default, a link to
# the last page does not exist in the index pages).
#
# A possible fix is to have a resource to tell mhonarc to also base
# index page updates by the change in last page filename. I am unsure
# what would be the best name for such a resource (eg. USINGLASTPG).
#
# BTW, to have mhonarc auto-detect if $LASTPG$ is being used would be
# expensive since it would have to scan every page layout resource to
# see if the variable is being used.
#
# Note, you should be aware that everytime a new page is added to an
# archive, all the index pages will have to be regenerated. This can
# get expensive if the archive is large. A possible enhancement to
# mhonarc is to support user defined actions during an archive update.
# For example, if I can tell mhonarc to create a symbolic link from a
# symbolic last page filename to the actual last page filename, then
# one can avoid all the index pages from be recreated (assuming that
# the index pages refer to the symbolic filename as the last page).
#
# Just a few more things to add to the to-do list,
#
# --ewh
#
#
