On Thu, Dec 02, 1999 at 04:06:33PM +0100, Alan Scheinine wrote:
> I have scratch space called /coda/tmp.  I do not know why, perhaps
> because of an abrupt shutdown, "ls /coda/tmp" give the result
> ls: /coda/software: Connection timed out
>   Connection State is Disconnected

The state is disconnected, so you are not allowed to read anything.
Funny, it looks like it has thrown out the root of that volume. It
should become connected again once it has managed to get rid of the CML
entries. I don't know why it does not become Write-Disconnected, that
could be because venus was restarted.

>   Write-back is disabled
>   There are 61 CML entries pending for reintegration
> 
> The same volume is usable from other computers.  Both the client
> and the server have been rebooted cleanly and yet the problem
> remains.  I am 99 percent sure that I will not be able to find
> a way to reintegrate the entries, I just want to tell coda to
> forget about the pending entries and connect to the volume.

Ok, first of all venus should be complaining in just about every log
(or at least /usr/coda/etc/console) that 'reintegration is pending
because uid xxx doesn't have tokens'.

To force the CML entries out (which discards all changes) use

  cfs purgeml /coda/tmp

I hope that works without the root-fid of /coda/tmp in the cache.
Flushobject or flushvolume are not very good choices as they won't flush
the CML, but will attempt to flush as many files as possible. And then
you won't be able to reach the volume anymore.

> I would really, really like to have again /coda/tmp on this
> particular computer.  How can that be done?

In the worst case.... reinitialize venus. Either start venus with the
-init flag or touch a file named /usr/coda/venus.cache/INIT and on the
next startup venus will purge anything it knows and start from scratch.

Jan