According to Jan Harkes:
>
>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
>

Well, there was one file that venus was looping hard on because there
was a zero length file in /usr/coda/spool that was associated with
that file (the name I don't think is important, it was called
internals.c - and it was just one of the files I had been working on
during the week)

>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.

No, I am sure there was plenty of free space at the time.
Unfortunately the tarball has been truncated, probably because I
interrupted the repair because it appeared to be hung - I knew that
that may be a dumb thing to do ;-)

> We
>don't handle all boundary conditions such as running out of diskspace
>that well.
>

I am _reasonably_ sure there was at least 20Mb free, I do not have
much data in my coda partition....

>
>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.
>

Ah ok.  I ditched the changes associated with that directory and I was
able to carry on with the repair but it looks like I lost my updated
internals.c - oh well, I did not lost too much work in any event.

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

I found that all too late, by the time I had looked at that I had
mangled it.  Oops, maybe next time....

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, BAE SYSTEMS
===============================================================================