(Illustration by Gaich Muramatsu)
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 LeBlanc_at_mcc.ac.ukReceived on 2000-05-03 08:58:29