On Wed, Feb 28, 2007 at 07:58:39PM +0100, u+codalist-p4pg_at_chalmers.se wrote:
> On Wed, Feb 28, 2007 at 04:48:53PM +0100, Enrico Weigelt wrote:
> >     cfs setacl /mnt/coda/jupiter.local/home/nekrad nekrad rlidwka
>
> Coda paths are assumed to be /coda/<realm>/files and not anything else.

In other words, several commands like 'cfs' and 'repair' assume they can
communicate with the running venus binary by opening /coda/.CONTROL and
sending a message with an ioctl.

Now if coda is mounted in another place such commands may or may not do
the right thing. If everyone mounts the Coda file system at /coda, I can
say that some file is available at
    /coda/testserver.coda.cs.cmu.edu/playground/foo

and everone can just point-n-click (or cut-n-paste) and get the file. In
fact that file may just as well be a symlink that points at some other
place in coda, maybe,

    coda-ftp -> /coda/coda.cs.cmu.edu/project/ftp/pub/coda/src

And this link will work correctly on any client that mounts /coda, but
a client uses a different location the naming breaks down and the
helpful pointers and symlinks will no longer work.

Now I do realize that sometimes people don't really care about all this
stuff, so if misbehaving applications are identified they will at some
point get fixed to use the alternate mount point.

I view it like locally renaming http:// to internets:// in such a way
that from then on any link you select on a webpage, or in an email fails
because the browser no longer understands 'http://', I guess for some
systems this could be viewed as a security feature.

Jan