Hi Eric,

> I use coda to centralize the distribution files for gentoo linux so I
> don't need to download the same package for each computer that requires
> it. I keep them in a volume called distfiles. The volume remains
> read-only for unauthenticated users and is writable by all members of
> the Portage group. This includes the username eric (me). This is the
> username I clog as root. The reason why I need to use root is because
> gentoo's "emerge" tool, the python script that installs and compiles
> packages, needs sufficient permissions to overwrite libraries and
> executables which are owned by root, and therefore needs to be run as
> root. This tool also requires write access to distfiles because it needs
> to download all of the packages and patches it requires. That is why I
> clog as root.

As I interpret the above, your cache of Gentoo files on Coda
can not be readonly and each host is going to write there.

Then yes, you have no choice. Pity. I guess emerge was developed without any
consideration of global filesystems - which will lead to problems, while it is
not Coda's fault, nor yours of course.

> Also, Rune, to the best of my knowledge, /coda is no longer the standard
> mount point, at least not in linux. Venus mounts to /mnt/coda by default
> on my system.

That is really bad.

You see, Eric, Coda has its standard mount point, which has nothing to do with
any OS, kernel or distribution. It concerns Coda file system on any platform.

I am sorry to tell that but the maintainer of Coda support in the Linux
distribution of your choice has in fact made a disservice to the users.

Alas, few of (even the brightest) distribution developers realise a presence
of global file name spaces.

> Jan Harkes wrote:
> > I'm fairly sure there are still a couple of places where it is assumed
> > that Coda is mounted at /coda.

And essentially it is very good for reminding the distributors
about the essential properties of global file systems :)

It _might_ be useful to be able to mount Coda at some other place,
for troubleshooting or in rare exotic situations.

Still, arbitrary mounting does not have to be supported for regular operation,
in my not so humble opinion.

> > The repair tools are trying to send ioctls to /coda/.CONTROL, which
> > doesn't exist. You can strace the repair tool and see which system call
> > is returning ENOENT.
> 
> This seems like the most likely problem. Next time, I get an
> inconsistent object, I'll try an strace to verify this. If it's true,
> I'll see about filing a bug report.

Please file it to your distribution maintainer, it is his/her fault,
really!

> The real solution,
> of course, is fixing the repair tool, if indeed something is wrong.

The real solution is moving your Coda mount point to the proper place.

It may seem not evident at all from your current (Gentoo-centric ?) point
of view, but it makes a huge difference in the long run.

The main point is "to be able to reach the same object via the same path
on any computer". Not only on the computers administrated by you, not only
on Gentoo, not only with Linux kernel...

There is hardly any other file system besides Coda which can offer that
functionality (AFS is almost there but not anyhing else). It is not very clever
to destroy that unique capability by a choice of an incompatible mount point.  

Best regards,
Rune