Coda File System

Re: Coda-client-setup 0.5 released

From: Jan Harkes <>
Date: Thu, 10 Mar 2005 17:53:41 -0500
On Tue, Mar 08, 2005 at 01:10:47PM -0500, Greg Troxel wrote:
> Tom Ivar Helbekkmo <> writes:
> > I have, until recently, been using Coda on a server to hold my $HOME
> > for my laptop.  It behaved just great for between one and two years
> > (Greg, you may remember helping me figure out some routing problems I
> > had switching between wired and wireless networks), except for hangs
> > in a very specific situation: if I let my tokens time out, while the
> > laptop was connected to a network, any attempt to access the file
> > system would fail, and the only possible fix was to very quickly use
> > an already open terminal window to re-authenticate.
> Odd, I have never seen this.

Actually, there is this annoying bug where a user with expired tokens
gets EACCESS on everything, even on those files that are accessible by

Only figured that one out a couple of days ago. I think it got
introduced with or shortly after the realms code got merged, so the
problem has been around for a while.

> > Even then, the
> > whole system might hang shortly thereafter -- and if I wasn't quick
> > enough to re-authenticate, but kept trying to access files, it would
> > most certainly hang.  Hard reset only option.
> I am suspicious of how venus handles revoking objects in the cache
> that are still open in the kernel.  I don't have $HOME in coda, just
> bits that I symlink in, so I am much less likely to have files open
> all the time.

So am I, there are a couple of places where we seem to use 'fsobj::Kill'
a bit eagerly and that operations pretty much pulls the rug out from
under the kernel. But it is hard to figure out exactly what correct
way(s) are to get rid of objects under various conditions. I once tried
to replace the cache replacement with something real simple (like an
LRU) and everything started breaking in unexpected places.

Received on 2005-03-10 17:54:27