First of all, thanks for your help.

Now, I have switched to use venus version 6.0.7, the strange errors seems 
doesn't happen again. But there's still errors when I start venus.

I check the venus.log and here are the messages:

[ W(20) : 0000 : 10:14:11 ] Cachefile::SetLength 512
[ W(20) : 0000 : 10:14:11 ] fsdb::Create: 
(50224f88.ff000001.fffffffc.5017d048,
62500) failed
[ W(20) : 0000 : 10:14:11 ] fsdb::Create: 
(50224f88.ff000001.fffffffc.5017d048,
62500) failed
[ W(20) : 0000 : 10:14:11 ] fsdb::Create: 
(50224f88.ff000001.fffffffc.5017d048,
62500) failed
[ W(20) : 0000 : 10:14:11 ] fsdb::Create: 
(50224f88.ff000001.fffffffc.5017d048,
62500) failed

And I also find that I can't create any files in the coda directory even 
after I've clog as an administrator and got the token.
Could anyone give me more help?

Thanks in advance,
Alvin Chan

----- Original Message ----- 
From: "Jan Harkes" <jaharkes_at_cs.cmu.edu>
To: <codalist_at_coda.cs.cmu.edu>
Sent: Friday, April 29, 2005 10:32 PM
Subject: Re: Venus error


> On Fri, Apr 29, 2005 at 07:23:08PM +0800, Alvin Chan wrote:
>> 18:10:47 Coda Venus, version 6.0.9
> ...
>> 18:46:22 Starting RealmDB scan
>> 18:46:22        Found 592 realms
>
> Huh, 592 realms? where did those come from?
>
>> 18:46:22 starting FSDB scan (833, 20000) (25, 75, 4)
>> 18:46:22        591 cache files in table (0 blocks)
>> 18:46:22        242 cache files on free-list
>
> And 591 file objects, I would have expected at least nr-realms + 1.
>
>> 18:46:22 /coda now mounted.
>> ***LWP (0x811ca90): Select returns error: 4
>>
>> Assertion failed: !STREQ(name, ".") && !STREQ(name, ".."), file 
>> "/usr/src/redhat /BUILD/coda-6.0.9/coda-src/venus/fso_cfscalls2.cc", line 
>> 470
>
> But this is the strangest one of all, this is when fsobj::Lookup is
> called for '.' or '..'. However every path that I can find that leads to
> this function either has,
>
>    /* don't allow '.', '..', '/' */
>    verifyname(name, NAME_NO_DOTS);
>
> Or it has special handling for the '.' or '..' objects. i.e.
> vproc::lookup immediately returns the directory on which we tried to
> perform the lookup itself, or returns it's parent directory, but never
> actually calls fsobj::Lookup.
>
> I have no idea what is going on with your client.
>
> Jan
>
>