Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!RODAN.ACS.SYR.EDU!jdpeek
From: jdpeek@RODAN.ACS.SYR.EDU (Jerry Peek)
Newsgroups: comp.mail.mh
Subject: Re: XMH cache
Message-ID: <9008231028.AA18521@rodan.acs.syr.edu>
Date: 23 Aug 90 11:28:44 GMT
References: <Raeburn@mit.edu> <9008230524.AA07100@PROMETHEUS.MIT.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 31

> One of the things I like about xmh is the .xmhcache file it
> maintains...  Running any other MH program that alters the folder
> directory causes xmh to rescan the entire directory to rebuild
> that file...
> 
> Does anyone have patches (hacks, suggestions) that would allow
> for maintenance of such a cache?

The .xmhcache file basically just holds the output of 'scan -width 100'
for the folder.  (The width comes from the TocWidth resource entry.)
A simple-minded fix would be to run a program that compared the
last-modification time of the .xmhcache file in a folder to the messages
in the folder.  If any message is newer than the .xmhcache file, the cache
needs rebuilding.  I'm not sure I understand your filesystem and network
setup, but I'd bet you could do the rebuilding on the host where the
folder lives... then copy the new .xmhcache file to your local host.

If xmh was running at the time, though, it wouldn't know that the .xmhcache
file had been updated -- so, the Table of Contents display wouldn't be
updated.  This fix would probably only work when you're *not* running xmh.

> Does anyone else think it
> would be a good idea for an addition to MH proper, as an extra
> option (preferably runtime-selectable, I'd say)?

No.  Because MH is a bunch of separate little programs, it's easy to use
in shell programming.  I think a short shell script that runs 'find -newer'
to compare the messages, then does the 'scan', should just about do it.

--Jerry Peek; Syracuse University Academic Computing Services; Syracuse, NY
  jdpeek@rodan.acs.syr.edu, JDPEEK@SUNRISE.BITNET        +1 315 443-3995