Michael Tautschnig <michael.tautschnig_at_zt-consulting.com> writes:
[...]
> How does coda get to know this mapping? On which basis does it map? I thought 
> it was the uid, but that doesn't make sense anyway...
Actually I don't know for sure, but read Jans answer again,
and check whether he said it is based on the token only.

> But what happens if you get disconnected? In what way is access control done 
> on cached objects or for creating new objects?
Again Jan will be the definite answer, but you still have 
a token that has your identity in it (clog -fromfile)
needed in the client. Such a stored (and probably expired) 
token is just not sufficient to talk to the servers.

> BTW - where will I get in trouble when using large caches (e.g. > 1GB on 
> laptops)?
We have that here, and on a PIII-600 you'll have some 20-30 sec.
delay after startup, until venus comes up. Should be better 
with modern hardware, but it reads/maps the whole 1gb.

> My users will like to be able to change access rights on their files (e.g. 
> what about making files executable) and e.g. give a virtual group access to a 
> project - how could they do that? Furthermore they probably prefer to do it 
Better than in Unix, they can give 17 users (or whatever) 
permission to read/write some directory. Or give access 
to a (coda-)group and still deny it to one group member.
Remember: its directory-wise access control,
not on individual files.

> using chmod/chown ...
No Way:

	cfs setacl ....

Yours,
Steffen