Hi Greg,

On Sun, Mar 10, 2013 at 10:18:28AM -0400, Greg Troxel wrote:
> Is there a pointer to the code/instructions and perhaps bug tracker/wiki
> site?  I have heard about ulocoda only here and only recently, and I

There is no special bug tracker, nor is it documented on the Wiki yet
afaik. The code is at http://www.gitorious.org/ulocoda
It is known to work on MacOSX 10.5.

When I am at the right computer I may try to write down the steps
I had to take to compile and start Ulocoda.

> wonder if this is coda via FUSE, or something else?  Also I'd like to
> try it.

It is implemented by preloading a dynamic library so that file name
operations involving "/coda/....." are redirected to a venus daemon,
quite similarly to what the Coda kernel module otherwise does.
This is slightly more complicated as the library must maintain some
bookkeeping usually provided by the kernel, which is done via
an extra daemon "terra" but that's it. The Coda cache and its venus
are shared basically as "one cache/venus per local user id" even though
the granularity is not restricted.

This can be run as one venus per host - if the superuser is to be involved
- but even given superuser cooperation separating caches per user brings
certain security advantages.

Ulocoda relies on the fact that the applications use a dynamically loaded
standard library which allows interception of file operations.

Glibc does not :b
Nevertheless we can let any open source program use a C library of our
choice, including support for Ulocoda. Thus Ulocoda can be used on any
platform including Linux, making Coda independent of the local superuser
and of kernel interface changes, which otherwise killed e.g. Darwin Coda
kernel module.

It would certainly make our lives much easier if we get Ulocoda on *BSD.

With all due respect, FreeBSD kernel developers seem to be particularly
bad at (interest in?/understanding of?/)maintaining distributed file systems,
not only concerning Coda, I experience this with NFS4 as well.

Cheers,
Rune