On Sun, Oct 15, 2000 at 03:27:05PM +0930, Brett Lymn wrote:
> 
> Folks,
>         My laptop crashed and it seems to have damaged my coda volume,
> venus would not start.  I did a bit of investigation and found that
> venus was looping on a zero length file in /usr/coda/spool (looks like
> a bug)  I was able to get venus past that by putting a byte in the
> file but now it complains with this error message:

Ehh, what file exactly, Coda snapshots disconnected modifications to
/usr/coda/spool/<userid>/<volumename>.cml and more importantly because
it contains the disconnected changes
    /usr/coda/spool/<userid>/<volumename>.tar

In cases like this, check that tarball to see if it has your changes,
maybe the looping was because there was no more diskspace available. We
don't handle all boundary conditions such as running out of diskspace
that well.

> Local inconsistent object at /coda/working, please check!
> 
> I have run repair on the volume to try and get rid of the
> inconsistency (I know exactly what the file is and just want to kill
> it from the update log) but partway through I get this:
> 
> repair > checklocal
> local mutation: create /coda/working/local/testframe/Makefile
> no conflict
> repair > preservelocal
> create semantic re-validation failed (60)

It could be that /coda/working/local/testframe was lost from the cache
due to some error, in any case, after reintegration the fid has changed,
but that shouldn't be a problem at all. Any volume under repair is in a
disconnected state, so the client cannot re-fetch this parent directory.

> Note that the directory /coda/working/local/testframe is a directory I
> created while disconnected, the entry to preserve that change worked
> fine.  I am using the 5.3.5 coda client on a NetBSD 1.5 machine.
> 
> Naturally, I am keen to get my changes back if I can ;-)

Check that tarball first, it is sometimes the best bet for recovery.

Jan