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....
Perhaps venus didn't succeed to write connect the server, made the change in disconnected mode locally ?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).
I guess deleting the /usr/coda/spool data push it in a no-reintegration possible way....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.
It shouldn't...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,
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....
Yep... it works !- 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?
I used debian build and don't have such a way of message.....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, [EMAIL PROTECTED]"
"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 !
