[...]
>
> In any case, you might consider replacing the file with a symlink to a
> local disk directory. Xauthority really isn't supposed to be shared
> across systems and Coda's directory ACLs probably aren't really
> protecting it as the UNIX modebits are more like a hint interpreted by
> the client, not a rule enforced by the server.
Ok, but this would not actually solve the problem, just bypass it :-)

[...]
>> venus.log contains the following entries:
>>
>> [ W(2830) : 0000 : 23:47:33 ] fsdb::Get: trying to access localized object
>> 5539d148.7f000002.1.1
>> (many times)
>
> Strange, which version of venus is this?
6.0.7 plus (maybe) some fixes in CVS soon after 6.0.7 has been out.

[...]
>
> Since it seems to be a reintegration conflict, the object in conflict
> should be one involved in the first operation in the cml checkpoint
> file (/usr/coda/spool/<userid>/<volume>.cml, it might also be in
> /var/lib/coda/spool). Alternatively, cfs getpath 7f000002.1.1_at_TIKI, but
> I think that call is mostly resolved in the kernel, so it depends on
> whether the kernel actually has the object cached or not.
>
Ok, but at least I will try to find out the next time I get such a 
conflict...

> In any case, since the vnode.uniquifier is 1.1, this object is the root
> directory of the volume 0x7f000002. (which is probably the directory
> /coda/TIKI/tautschn.
Yes.

> I guess something has a reference to the directory, for instance all
> your shell windows and applications that happen to have their current
> working directory set to your home directory. As a result we can't turn
> the directory in a dangling symlink which is why the conflict is
> invisible (and unrepairable).
Ok, I get the point.

[...]
>
> The problem is really twofold, first of all the code is trying to change
> an existing object into a dangling symlink, which is a pretty nasty
> operation for the kernel especially when the object is considered in
> use. The second is a Linux kernel 'issue' which is that anything that
> has a reference to a directory cache entry, such as the current working
> directory of a process, automatically has a reference on the inode
> (making the object 'in use'). Probably the only way around this is to do
> something similar to the NFS 'silly rename' when a referenced file is
> removed on the server, the referenced object is moved aside, and in our
> case would be replaced by a new object that represents the dangling
> symlink.
>
Well, why do you use those dangling symlinks at all? Couldn't venus just 
keep a record of the file/directory being in conflict - or is that 
dangling symlink all venus/kernel share as a knowledge of an object being 
in conflict?

I just thought of something like CVS' internal structure, keeping track in 
the RVM or in /var/lib/coda/spool - such that (in case of a conflict) no 
modifications to the volume itself are necessary - IMHO this should at 
least be feasible for local-global conflicts.

Any thoughts?

Thanks for your help,
Michael