Well, it seems to be pretty stable on our webserver and the fileservers
that handle the www volume. In fact I haven't had to repair a
mailinglist archiving related conflict in the past week :)

So it's about time for a new release.

Coda-6.0.2
----------

Lots of fixes all over the place,

- avoids client disconnections when the server is busy computing SHA checksums.
- no zombie processes left behind after mounting /coda.
- '..' traversal across volume mountpoints now does the right thing.
- cfs la on fake objects works.
- allow mounting of a cloned volume.
- more repair fixes (the never ending story, repairing repair)
- updateclnt would forget to reconnect to updatesrv.
- pdbtool can now handle very large groups (group with thousands of users).

Some interesting features were added as well,

- redzone/yellowzone for mutating operations while (write)disconnected.
  Slow down when the modification log starts to fill up, and actively
  block threads before they get any locks when we are pretty much out of
  space. This allows the reintegration thread to catch up.
- removed per-user rpc2 connection limit.
- masquerade is now always used. there really is no reason to keep rpc2
  and sftp on separate ports.


Along with this comes rpc2-1.19,

- Removed MultiRPC pool allocator, now we can have more than 8
  concurrent RPC operations. And because the per-user limit got removed
  in Coda-6.0.2, this is more likely to happen.
- A packet with random data could easily trigger an assertion in the
  MultiRPC decoding. Now we simply drop it and avoid the possible DoS.

- IPv6 support, it is just waiting for the right flag from userspace.
  As a result the 1.19 API is binary compatible for older clients and
  servers.
- Removed sftp listener and timeout threads. We always run what was
  previously called 'masqueraded'. This works fine as long as our peer
  uses rpc2-1.9 or later.

I uploaded the sources to /pub/coda/src, and whatever binary packages I
had lying around (Redhat-5.1, Redhat srpms, debian-stable and
debian-unstable). So most people will probably have to build from the
SRPM or source tarballs.

Jan