Coda File System

Re: Problems in disconnected operation

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Tue, 2 May 2000 12:05:03 -0400
On Tue, May 02, 2000 at 09:38:05AM +0100, Dr A V Le Blanc wrote:
> I often find that in one or another directory, during disconnected
> operation, I am not allowed to edit or delete files, while in
> other directories I have no problems.  I do have a coda token
> saved.  I can't check ACLs while disconnected, but I suspected
> there might be some discrepancy there.  But when I returned
> to the network, I am confounded to discover that the ACLs are
> exactly the same on two subdirectories, to one of which I had
> write access, while I was refused it in the other.

A Coda client caches `trust', not the ACL's. When a file is fetched by a
user the client and the server gives it, the client remembers that that
user is allowed to access the file. The hoard daemon fetches files
according to the uid of the user who submitted the hoard entries.

So if you have several users, or the hoard daemon doesn't access the
files with your identity and the ACL doesn't permit System:AnyUser
access, the permission will not be recorded in the cache.

> It's about a week now before I give the first public presentation
> of the talk on Coda I've been putting together for the last few
> months.  I haven't got an online version quite ready, but I
> hope it will be in a couple of days.  Meanwhile, as a matter of
> interest, are read-only replicated volumes still supported, or
> have they now disappeared completely?

Hmm, they are still there. Mainly because the backups and volume
replicas underlying replicated volumes are using the same
non-replicated volumes as a read-only replica would use. But we can't
revalidate the cache after disconnection. Ofcourse, we should never
need callbacks or cache revalidation on read-only replicated volumes,
except for maybe a volume level callback.

Personally, I'd like to consider them dead, as handling special cases
such as this is what makes the code so much harder to maintain. We
already have 3 different code-paths for normal operations depending on
connectivity state (disconnected, write-disconnected, fully connected).
Having two distinct cases for revalidation and callbacks doesn't seem
too attractive right now.

Jan
Received on 2000-05-02 12:22:06