Thanks again for the swift replies.
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.
On Tue, May 02, 2000 at 12:05:03PM -0400, Jan Harkes wrote:
> 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.
I have only two users in this cell, and the one running hoard and
saving the token and running remotely is also the only member
of System:Administrators. I find also that hoard does not work
on directories to which I have all access, unless I also give
System:AnyUser lookup access.
The problem directory has ACLs System:Administrator all, System:AnyUser
rl, and me all. Other directories with the same ACLs and in the same
volume are not having problems. I haven't got the hoard file in
at work today, so I can't say how the volume in question is handled;
I thought it had d+ with a small priority on the whole volume, and
higher priorities on various files which are more heavily used.
> 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.
As a matter of interest, why is the System:AnyUser access required?
> 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.
It seems a sensible way to go, though it's tempting to ask whether the
read-only replicas are (or could be made to be) much more efficient
in some way, as it would appear to an old AFSer that they might.
Thanks again.
-- Owen
[EMAIL PROTECTED]
