On Fri, Feb 23, 2001 at 04:41:29PM -0800, Ken McMillan wrote:
> 
> Is it possible to restart the Coda client in disconnected mode?  I
> often find I have to reboot my laptop when it is not connected to the
> network. Coda fails to restart because it cannot talk to the server,
> and thus I cannot access my cached files. 

Coda is perfectly capable of starting disconnected as long as it can
resolve the hostnames of the servers that are mentioned as "rootservers"
in the configuration file. So you'll probably have to add the name of
your server with it's ip-address to /etc/hosts.

> Also, I have had some serious trouble with Coda and shared libraries. 
> That is, suppose you are running a program on machine A which is using
> shared library libfoo.so. While it is running, you recompile libfoo.so
> on machine B. If you then try to run (another instance of) the program on
> machine A, you get the message:
> 
> 	libfoo.so not found
> 
> This is a bit odd, since ls shows that libfoo.so is still there,
> though its date is old. Apparently, coda cannot kick the old version
> of libfoo.so out of the cache so long as it is still in use, hence it
> cannot read the new version in, and it cannot report a "conflict" for
> libfoo.so, for the same reason. This is highly confusing, and doesn't
> match the unix file system semantics. That is, if libfoo.so were
> stored on the unix file system, and I recompiled it, the version that
> was "in use" would be unlinked. Thus, the original process that was using
> libfoo.so could continue running, and new processes using that library
> would see the new version. Wouldn't this kind of behavior be possible
> in Coda as well? That is, if a file that is "in use" is removed, would it
> not be possible for Coda to keep a temporary copy of that file until
> it is no longer is use, while removing it from the cache?

Coda faithfully uses AFS semantics, not unix semantics, and it is quite
difficult to present a different view on the filesystem for different
applications. In any case, the originally running applications should be
using libfoo.so.<x>.<y>.<z>. While the newly started applications would be
loading the updated libfoo.so.<x>.<y>.<z+1>. Library versioning does
have reasons.

It is most likely not even Coda's fault that the new library isn't
found, but the fact that the dynamic linker ld.so is using a local cache
file with library locations (/etc/ld.so.cache), which is only updated
after you rerun ldconfig on the client. This is usually done by your
package installers or makefiles, so it is normally not noticeable on a
single machine.

Jan