Did not pop today's post...
I'm a little bit in late as usual, why isn't there 36 hours in a day ????

>I'm planning for moderate numbers of big files, so it sounds like I'll be OK.
>

The best configuration yes....

>I have seen something like this on my test setup, which is an old (2y) BSD
>server (FreeBSD 2.5) with old coda server built from the ports collection, and
>the latest coda client (I think; see below) on my linux notebook. What happens
>is a bit mystifying. I can mount the filesys, make files, see them, everything
>is good. Then I delete a file on my client and suddenly coda gets quite
>unhappy, dropping a conflict packet in /usr/coda/spool (an empty tar ball & a
>cml file listing the delete op).
>
Perhaps venus didn't succeed to write connect the server, made the 
change in disconnected mode locally ?

> Then it bitches about inconsistent or
>unresolvable hoo-ha. If I try to run repair(1), beginrepair refuses to
>acknowledge there's a problem, claiming "Could not allocate new repvol: Object
>not in conflict." So I'm hosed until I nuke the entire client setup with a big
>hammer like venus-setup and start over.
>
I guess deleting the /usr/coda/spool data push it in a no-reintegration 
possible way....

>I *don't* lose when I'm using venus locally on the BSD box, which is the
>older client -- the whole coda setup on the BSD box was built from the
>ports collection that came with the OS (FreeBSD 4.5).
>
>I figured this was due to client/server skew, what with the old coda
>server & the new coda client,
>
It shouldn't...
I was running new clients 6.0.x against 5.3.20 coda-server version for a 
while without any trouble...

> and was going to upgrade the server. But that's just a guess. 
>
Server side did not change too much for version 6..
And as you can see in Changelog new client is compatible with old 
coda-servers...

>Now I see your comment about fake conflicts due to
>thin-pipe write disconnects. Can someone tell me why this happens?
>

That would not be me sorry....

>  - I lost due to the "your kernel is too old" err msg when venus came up.
>  - I patched the kernel sources with the linux-2.4-coda.patch from the coda
>    download site & recompiled.
>  - Victory.
>Is this the righteous path?
>
Yep... it works !

>What is a little confusing to me is that the client rpm is named
>"coda-client-6.0.3-1" but when venus comes up, it says
>    "Coda Kernel/Venus communications, v5.3.18, coda_at_cs.cmu.edu"
>
I used debian build and don't have such a way of message.....
"Coda Venus, version 6.0.3" in /var/log/venus.err...
By the way, the fact that kernel had complained for the kernel version 
show that your on a 6.0.x version...

>5.3 seems a long way from 6.0. Are venus release numbers distinct from those
>used for a larger "coda client" package entity?
>
I would say no...
Perhaps a forget-modification ?

-- 
Lionix
FS-Realm (newbee?) Administrator
Hundreds hours of work but so powerful !