You're of course right, but since we're already planning the VPN, I don't really want to move the file off - and IMHO it would be quite some work, as we are using kdm ...
one suggestion, I would rather not put ones .Xauthority on Coda.
There is no encryption on the data, so unless you run Coda traffic over VPN, you open some nasty holes to your desktop.
Sorry, but I didn't really get the point - what does "occupy" mean here? Or does it simply mean, that I sit in that directory - but if so, why should my whole directory be in conflict?
On Sun, Jan 23, 2005 at 12:00:55AM +0100, Michael Tautschnig wrote:Since I'm using Kerberos, but usually logging in using my ssh-key, I repeatedly get in trouble, probably because of expired tokens. This usually results in
timeout in locking authority file /coda/TIKI/tautschn/.Xauthority
These problems are somewhat annoying, since I don't really know, what venus is telling me - and how to solve the problem without a need to restart venus all the time...
The problems can depend on the situation when the conflict is created - you login and "occupy" the directory, so Venus has hard time exposing the conflict, it cannot do with busy objects. Just a guess...
One primary problem is: How to find the object being in conflict? venus tells me some Fid - but how do I map it to some path name? Maybe "cfs getpath" would be the answer, but how to use it? Which part of
LocalInconsistentObj: objFid=5539d148.7f000002.1.1
maps to %x.%x.%x@<realm> ?
Thanks, Michael
