On Tue, Mar 20, 2007 at 10:33:11AM +0100, Enrico Weigelt wrote:
> how can I get write access to my coda files in disconnected mode ?
> 
> If I authenticated while online and then disconnected, it seems to
> work somehow, but the client must not have been rebooted for that.

This is an argument that has been ongoing for a while. Only a server can
really validate if a user has write permission, the client caches some
of this information to avoid having to pass every request to the server
and to survive during disconnections.

However if you lose your tokens (expiry or client restart) then even if
you give the client a new token it can't tell if the user identified by
the new token has the same rights as the original user who fetched the
files into the cache.

Coda used to agressively discard all cached rights when tokens expired,
or when the client was restarted. Very annoying for disconnected users
as they had to reconnect, authenticate and re-hoard to recache their
permissions.

Right now we actually keep the permissions around until we reconnect and
we don't drop tokens until the server tells us they have expired. I
think the client may also drop cached rights on reconnection. This
behaviour is a little more useful, you can actually save the token to a
file on the local disk (clog -tofile codatoken), and after a client
restart pass the saved token back to venus (clog -fromfile codatoken).
As the client can't check if the token is still valid it will allow
access to your files. However once you reconnect and the token is deemed
invalid all cached rights are immediately revoked and if you then
disconnect the token would be useless since we don't have access to
cached rights anymore. Also if you should have access to some object,
but another user fetched it during the connected period but your
identity has not accessed it until the client got disconnected  there is
no cached information that states that you actually do have read or
write permission.

Then there is the argument for single user clients to never bother
checking cached rights, so we'd have read/write access to anything and
the server will simply prevent us from reintegrating anything we don't
have permissions for. This is very useful for a single user client, but
could be a problem when there are several users using the same client
because everyone could potentially change every file, and although those
changes would never propagate to the servers they are locally visible to
the other users. i.e. if /bin/login would be a link to some binary in
/coda anyone could replace it with a trojan and capture passwords from
other local users.

Jan