> Yeah, that is fixed with the 6.0 servers. It only happens when you have
> singly replicated volumes, and all of our volumes happen to have 2 or 3
> replicas so I never hit the problem. Basically the version vector test
> is too restrictive and the reintegration will abort due to conflicting
> updates (in fact updates it just reintegrated from the same client
> moments ago).

Ah, thanks!

About 6.x - is the vanilla source compilable on FreeBSD (4.8)? I am getting 
errors pretty fast about redefinitions of types when it compiles 
kerndep/pioctl.c (which I assume is needed for the client only?).

I understand from the previous thread that someone supposedly has 6.x, even 
the client, working on FreeBSD 5.x, which would indicate 6.x is "supposed" to 
work on FreeBSD. Any special procedure needed to compile it, beyond what is 
in the cocs? Is the FreeBSD realms patch on the FTP site (for 4.8 and 
current) for realms support for 5.x, or is it meant as a patch to make the 
Coda 6 client work?

I was going to stick to 5.x for now and wait for 6.x to make it into ports, 
but if the re-intergration problem is fixed in 6.x I'd like to have a shot at 
it.

> We don't automatically unmount on linux because that fails pretty much
> all the time (i.e. as long as any process has it's cwd in Coda or a open
> file reference).
>
> But after killing venus you can always try to unmount it by hand, and if
> that fails search around with lsof for processes that have a reference
> to /coda (lsof | grep /coda) and kill those and retry the umount.

MIght have been it, not sure. I'll have a go next time. But the kernel support 
is definitely killed because "df" yields complaints about missing upcalls 
afterwards.

Thanks a lot!

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller_at_infidyne.com>'
Key retrival: Send an E-Mail to getpgpkey_at_scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org