I'm going to upgrade to this today. I came in this morning and found two computers with hung coda clients. This is the first time in a while this has happened. Both of the clients had these log messages (sorry I can't give a backtrace -- these machines were don't have gdb):
[ D(31) : 0000 : 09:00:00 ] userent::Connect: VGAPlusSHA_Supported -> 1
[ W(30) : 0000 : 09:00:00 ] userent::Connect: Authenticated bind
failure, uid = 0
[ W(30) : 0000 : 09:00:00 ] WAITING(SRVRQ):
[ W(20) : 0000 : 09:00:00 ] userent::Connect: Authenticated bind
failure, uid = 0
09:00:00 Coda token for user 0 has been discarded
Assertion failed: p->ai_family == PF_INET, file
"/home/pwalsh/working/coda/BUILD/coda-6.0.10/coda-src/venus/realm.cc",
line 182
Hopefully the update will fix this problem...
..Patrick
On Tue, 2005-06-07 at 16:27 -0400, Jan Harkes wrote:
> Coda-6.0.11 has been released.
>
> Binary packages have been built on Redhat 9.0, Fedora Core 2 and Debian,
> SRPM and the source tarball are also available.
>
> This release consists mostly of small fixes, it shouldn't be necessary
> to reinitialize the client. The most important changes are,
>
> - Fixed kernel device check in venus-setup. (Maurice van der Pot)
> - libc5 compilation fixes. (Dan Fandrich)
> - Reintegration of 'mkdir bar; chown foo bar' was incorrectly considered
> as a conflicting update.
> - Fix iterators to make sure we keep objects pinned down with a refcount to
> prevent them from being pulled out when we yield (make an RPC2 call) during
> the iteration.
> - Send error messages from the backup scripts to [EMAIL PROTECTED] instead of
> the
> current (/dev/null-ed) addresses in the Coda domain.
>
> We have been running the new clients and servers for a couple of days
> already to see if the iterator changes introduced any unforeseen
> problems, and everything seems to be working just fine.
>
> Jan
>
--
Patrick Walsh
eSoft Incorporated
303.444.1600 x3350
http://www.esoft.com/
signature.asc
Description: This is a digitally signed message part
