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.
[...]
Ok, but at least I will try to find out the next time I get such a conflict...
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 [EMAIL PROTECTED], 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.
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.
[...]
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?
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.
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
