>
> 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.
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 ...

>
> 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...
>
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?

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