u+codalist-p4pg_at_chalmers.se wrote:
> Hello Eric,
> 
> unfortunately I can hardly guess what is wrong in your situation,
> may be more detailed description of your setup and how you get the conflict
> might help.
> 
> (CML is "cache modification log", a recording of what
> has been done to an object, like "create", "rename", "remove", "store")
> 
> Going a bit offtopic:
> 
> I notice details which are preferably avoidable in Coda administration.
> 
> You mount Coda at a non-standard place instead of the standard /coda.
> 
> Normally Coda gives the same view of the files on any computer in the world.
> You are making your given Coda client incompatible with the rest
> of the Coda world (e.g. symbolic links do not work on your client the same
> way as for all others).
> 
> Another more subtle thing is administrating Coda as Unix root user,
> it is a bit dangerous.
> On one side there are usually many processes running
> as root on a particular host and you do not always want all of them
> get rights over distributed files (used on other hosts as well).
> 
> On the other side, the numeric value of a Unix uid is totally irrelevant
> for Coda.
> 
> To see it from another point, root should be clog-ed to Coda only in cases
> when you want the corresponding host's system processes to have certain rights,
> like running cron jobs and updating files on Coda. Still, it would be
> safer to run those jobs under a separate local uid and make that uid
> instead of root to clog to Coda.
> 
> Things a human does interactively is his/her activity, not the host's.
> It is best done under a separate uid.
> 
> You may know that AFS has been trying to attach distributed rights
> to something else than uid, and went for PAGs, creating ground for a long term
> confusion (they are still struggling with definition of the exact available
> and desired semantics of a PAG).
> Coda has a much simpler and cleaner approach, attaching the rights
> to an uid, which is _the_ identity on Unix-like systems.
> 
> Sorry for not being able to help,
> try to give more details, or may be somebody else on the list can suggest
> a solution.
> 
> Regards, Rune
> 
> 

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.

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.

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

> It is normal, the inconsistent objects are transparently moved to a
> local 'repairvolume', which is read-only. This is the volume that will
> be mounted under 'local' when the conflict is expanded. This is to avoid
> internal confusion between the locally modified files and the files on
> the server that will become visible under 'global' during the expansion.


> Easiest method if repair doesn't work is probably to discard all not yet
> reintegrated changes on your client,
>
>     cfs ck /path/to/volume      (creates a tarball of all changed files
> 				 in /usr/coda/spool/<uid>/)
>     cfs purgeml /path/to/volume (discards all local changes)
>
> Jan

Thankyou. I'll use this as a temporary solution. It appears much more
convenient than shutting down venus and re-running venus-setup, which
was what I used to have to do to get it going again. The real solution,
of course, is fixing the repair tool, if indeed something is wrong.

Thanks for all your help so far!

Eric