Michael Tautschnig <[EMAIL PROTECTED]> 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
