On Tue, Aug 19, 2003 at 07:39:56PM +0900, Stephen J. Turnbull wrote:
> Details on request, of course, but I get the impression you're not
> putting high priority on this right now.

Ok, I've been hitting my client (and servers) with reintegrations, and
copies and everything I've got and didn't manage to reproduce your
problem. (I did get an assertion in fsobj::Open, it looks like a
directory got purged as we were trying to access it).

However....

On Thu, Aug 14, 2003 at 02:23:01PM +0900, Stephen J. Turnbull wrote:
> Assertion failed: f, file "vol_cml.cc", line 2256

This assertion is interesting. When we're reintegrating, the
reintegration is smart enough to apply most directory operations to a
directory that was already modified on the server (because it was dirty
on the client it is missing a current version).

When reintegration completes, the server includes a list of 'stale
directories' that should be refetched by the client. And this assertion
triggered in the piece of code that tries to mark/remove the stale
directories. The assertion happens because the client can't find the
stale object (i.e. it must have already been thrown out).

So instead of asserting because we can't find it, we should probably
just 'skip' the (already removed?) object.

Jan

--- vol_cml.cc.orig	2003-06-01 19:03:52.000000000 -0400
+++ vol_cml.cc	2003-08-21 21:55:25.000000000 -0400
@@ -2253,10 +2253,11 @@
 		    LOG(0, ("ClientModifyLog::COP1: stale dir %s\n", 
 			    FID_(&StaleDir)));
 		    fsobj *f = FSDB->Find(&StaleDir);
-		    CODA_ASSERT(f);
-		    Recov_BeginTrans();
+		    if (f) {
+			Recov_BeginTrans();
 			f->Kill();
-		    Recov_EndTrans(DMFP);
+			Recov_EndTrans(DMFP);
+		    }
 		}
 	    }
     }