(Illustration by Gaich Muramatsu)
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. JanReceived on 2007-03-20 13:47:05