From xemacs-m  Mon Mar 24 07:22:22 1997
Received: from omega.intranet.com ([192.148.106.20])
	by xemacs.org (8.8.5/8.8.5) with SMTP id HAA10980
	for <xemacs-beta@xemacs.org>; Mon, 24 Mar 1997 07:22:21 -0600 (CST)
Received: by omega.intranet.com; (5.65v3.2/1.3/10May95) id AA29814; Mon, 24 Mar 1997 08:23:01 -0500
Date: Mon, 24 Mar 1997 08:22:11 -0500 (EST)
Message-Id: <199703241322.IAA19476@blight.IntraNet.com>
From: Jonathan Edwards <edwards@intranet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Kyle Jones <kyle_jones@wonderworks.com>
Cc: xemacs-beta@xemacs.org
Subject: Re: VM6.21 problem
In-Reply-To: <QQciey28183.199703240411@crystal.WonderWorks.COM>
References: <199703231311.IAA17626@blight.IntraNet.com>
	<QQcidi18708.199703231736@crystal.WonderWorks.COM>
	<199703240328.WAA20794@blight.IntraNet.com>
	<QQciey28183.199703240411@crystal.WonderWorks.COM>
X-Mailer: VM 6.21 under 19.15 XEmacs Lucid (beta103)
X-Face: #bA9Kpw-a@xMyaNJ-2wie(5Lje^S*i^8!VUOF84U!/jSPG*y@3s4Qu+\-FBQ?vQpE1S1<Vo
 TeWVx=wH}wf_WC]x:D%qd,r*|!~q=gVAWEA;T~3V4};X$r7W!FA(#Zj'E7M^(Tv)

Kyle Jones writes:
> Jonathan Edwards writes:
>  > There is something subtle and asynchronous going on here.  I
>  > have reduced the problem to one involving very large
>  > UNMODIFIED folders. These have large amounts of background
>  > activity (multi-second hangs) in vm-flush-itimer. [shouldn't
>  > the cache be empty?]. Further, it seems that sometimes vm-quit
>  > will treat an unmodified folder as modified and try to write
>  > it out to disk, which causes multi-minute hangs.
>  > [...]
> 
> (chuckle) I was hoping I wouldn't have to explain this stuff, but
> no one is going to believe me when I say this is normal behavior
> unless I do. :)  So...

[All pre-existing folder cache entries are considered changed by 6.21]

But I do not understand how this explains the inconsistent behaviour of
vm-quit. Usually I can quit from the folder instantly. In some
circumstances it decides it has to do mega folder changes. The folder
is in the same state each time.

More detail: these folders were created by procmail and are marked
read-only in VM. But there are some VM headers in the folder from
before I figured out how to make it read-only in VM.

Shouldn't all this cache updating be suppressed on a read-only folder?

In any case I will take your advice and let VM finally reorg the
folder. It takes more than 5 minutes, so I have never let it complete.

> See?  All normal.  The reason I wanted you to let VM finish what
> it was doing is that once it finished, you would not see the
> delay again unless I lengthened the cache further.

That is much better explanation than just "normal". 

