On Fri, Jan 10, 2003 at 11:54:56AM -0800, Rod Van Meter wrote:
> On Fri, 2003-01-10 at 09:21, ext Jan Harkes wrote:
> I just noticed that the clock on my server is a day ahead.  Not sure how
> that happened.  Will Coda barf if I move it back a day?

RVM will barf. The only way around it is afaik to shutdown your server
cleanly.

    volutil shutdown
    tail -f /vice/srv/SrvLog

and wait until it states that the server was shut down. Then make sure
the rvm log is completely truncated,

    rvmutl
    * o /path/to/rvm/LOG
    * status

Check if it says 'log empty: true'. If not, the command 'recover' should
commit any pending operations. Once you're sure that the RVM log has
been committed you can exit with 'quit' and set the clock to the right
time. We then have to initialize a new RVM log which will have the right
timestamp.

    rvmutl
    * i /path/to/rvm/LOG 20M
    * quit

Once all of this is done, you can restart the server.

> > Looking at the server code, I just noticed that when resolution is
> > disabled, the code uses a stronger test that would validate the store-id
> > of directories. And we've been turning resolution off on newly created
> > volumes that have only a single replica because of some other problem.
> > It could be that this has made reintegration more susceptible to
> > failures. This is just one theory, but
> >     'volutil setlogparms <volume replica id> reson 4'
> > will turn resolution back on. 
> 
> I tried this (see above), but didn't solve the problem.  Whether or not
> it would have stopped it from occurring in the first place, can't say.

It should stop it from occuring in the first place, not fix the problem
of conflicts not showing up.

> > Another interesting fact is that the first entry in your CML is a store.
> 
> Well, in mine, the first item in the CML is a Create, so assuming we're
> hitting the same bug, that's a red herring.

Correct, your bug is probably the fact that the server is too strict and
doesn't allow a new directory entry to be created if the directory
version is not what we expect and got introduced a couple of versions
ago when we started disabling resolution on newly created singly
replicated volumes.

The store bug is something that I believe has been present in Coda for
much longer and is the result of an aborted connected store which is
then queued for reintegration on the client, but has already completed
on the server. The reintegration fail because the object on the server
is not the same version as what the client expected.

Another thing I noticed. All the failed callbacks in your server log.
You must be going through a masquerading firewall that forgets about
what ports are being forwarded when the client is silent for too long.
As a result the server backprobes can't get through. Check the
'serverprobe' option around the end of /etc/coda/venus.conf.

Jan