For now, hold back on upgrading to rpc2-2.6.

If you are already running the latest rpc2 version, I have a fix, but I
want to make sure it really does fix the problem. I should have at least
something out by/before monday.


Phil Nelson noticed some unusual error values in his logs while testing
his Windows build of Coda-6.9.2. The importance of these unusual errors
escaped me at first but became clear once I started upgrading the CMU
Coda servers to the latest release.

The new errno translation code in RPC2 has issues. The problem is that
the system-to-rpc2 translation function was never called, while the
rpc2-to-system part of the translation was only used for multirpc
responses (i.e. by Coda clients).

This had gone mostly unnoticed because (at least on Linux/i386) the rpc2
and system error numbers tend to be for the most part identical and only
in some unusual cases do we use non-standard values, for instance when a
volume is not found or a conflict was detected. But such situation do
not occur all that frequently (and we correctly translated the responses
from the production servers that were still running the old code). The
updateclnt/updatesrv daemons also didn't exhibit any problems because
they were not translating on either side of the unicast rpc2 response,
so they were just using the wrong error values on the wire.

Of course once we upgraded some of our production servers the missing
translation became problematic because of the random mix of both old and
new clients and servers combined with quite a bit more activity and
server-server traffic during conflict resolution.


The current "hey it has been working reliably on my desktop/development
server setup for a couple weeks now, let's make a new release" strategy
is clearly not working. It also leads to last minute fixes for various
platform/distribution ports which makes it less clear whether the
source tarball/CVS tag really is identical to the one that was used to
build the binary packages that were not part of the initial release
(i.e. Debian debs/FC rpm).

So the release schedule has to change.

We will have one or more, probably source-only, pre-releases. As these
releases are expected to be ready they will be installed on (a subset of
our) production servers and clients to get better testing. This will
also allow us to make sure everything build on distributions/systems
that I don't have direct acccess to.

If no regressions are found or other changes are needed during the week
following the pre-release, it will be re-tagged as the final release.
Ideally, the only change for the final release will be the version
number.

Jan