(Illustration by Gaich Muramatsu)
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); + } } } }Received on 2003-08-21 21:58:39