On Tue, 15 Apr 2003, Jan Harkes wrote:

> Here beginrepair simply tells venus to expand the conflict. Once the
> conflict is expanded it checks the contents of the 'fake directory' to
> see what type of conflict this is. You can suspend repair (^Z) and do
> 'ls -l blah' to check for yourself. In this case it should have expanded
> to a local and a global directory. However the enumeration step failed,
> maybe we got completely disconnected from the servers and global is a
> dangling link instead of a proper directory (as I just noticed is the
> case further down in your email).

If the client goes into disconnected mode, why would it then get
completely disconnected from the server?  This is a desktop sitting
on a LAN.

> > If I do an 'ls -l blah' now, I get:
> >
> > lrw-r--r--    1 root     nfsnobod       27 Apr 15 13:35 global ->
> > @7f000000.000018f2.000007ef
> > -rw-rw-r--    1 samir    nfsnobod       14 Apr 15 12:19 local
>
> This is easily explained. The object does not exist on the servers, so
> ofcourse we cannot show the global object. I believe this conflict
> 'should' be propagated to a directory conflict in the containing
> directory. Perhaps it fails to do so because your shell process has
> 'pinned' down the directory and therefore we fail to turn the directory
> into a conflict. Or maybe there is something wrong in the local-global
> repair handling of store conflicts, this is an update/remove type
> conflict that hasn't been tested as frequently as update/update
> conflicts (when both clients concurrently try to update the file).

What are the plans [if any] on fixing these sort of things?

> > but I can't ever get the conflicts resolved.  The only way to get
> > things back to "normal" is to shut Coda down, and re-run venus-setup.
>
> 'cfs purgeml' will throw away all logged updates that are still waiting
> for reintegration. Once the logged updates are gone the conflict should
> be gone as well and the volume can become 'Connected' again.

Thanks!  I need to read the cfs man pages and the Coda manual a bit
more carefully.

> > Occasionally, I can't even cleanly shutdown Coda (get timeout error's
> > trying to access /coda partition), in which case I just reboot the
> > client.
>
> When there is any process with a reference to a file in the /coda
> subtree (f.i. working directory of a bash shell), the Linux kernel
> rejects the unmount. The timeout and EIO errors occur because there is
> no venus process listening for upcalls anymore. The only way out is to
> find and kill any processes that have references to objects in /coda,
> then umount /coda and then the client can be restarted.

That's what I thought...

> Jan

Thanks,

Samir