(Illustration by Gaich Muramatsu)
(Illustration by Gaich Muramatsu)
If all of the servers that an object resides on become inaccessible, then the client will use the cached copy of the object (if present) as a valid replica. When the client does this, it is operating in disconnected mode .
Disconnected mode may be the result of a network failure, or it could be the result of removing a laptop from the network. If you make sure all of the files you want to use are cached on your laptop, you can travel with it and access your files as if you were still on the network.
Unfortunately, a cache miss while operating in disconnected mode is not maskable, and you will get a connection timed out error message. Coda allows you to mark or hoard files with caching priorities to help keep the ones you want in the cache.
When you are in disconnected mode, you may want to checkpoint the modify log that Coda keeps of which directories have changed. Use cfs checkpointml to do this.
Checkpointing the modify log will ensure that changes you have made will not be lost if the cache manager crashes severely. The checkpointed log files are an identical copy of the in-memory logs that Coda uses when it re-integrates with the servers.
Coda adapts easily to low bandwidth connections like ( PPP or SLIP modem links). You can use this to periodically reintegrate and cache new files when you are on a trip.
When you reintegrate after operating in disconnected mode, keep an eye on your codacon output or run the command:
This file will let you know if the reintegration was successful. If it was not, then the files that you modified will be put in a tar file in /usr/coda/spool/ uid . Reintegration fails, for example, when you modified a file in disconnected mode and someone else also modified that file on the servers. Read Section 2.3 for more information on reintegration.