Please test OpenAFS 1.4.1 RC5

Folks.  If you read this list it can only be because you care about the
quality of the OpenAFS for Windows releases.  Some point over the next
48 hours, 1.4.1 RC5 is going to be announced.  When it is, please take
the time to download, install and test this build.

Between 1.4.0 and 1.4.1 RC5 there have been a greater number of changes
to the internals than I would like.   The development work leading up to
1.4.0 focused a lot of energy on the thread safety and memory management
of the cache manager code.  After 1.4.0, a significant effort was spent
on cleaning up the SMB Server implementation.  The changes to the code
are not supposed to impact the behavior experienced by the end user
other than to make the application work correctly in more situations.

The re-writing of the SMB Server was triggered by two events:

First, the implementation of the client side byte range locking in the
SMB Server requires that all file handles be closed when the SMB client
unexpectedly disconnects from the SMB server and then reconnects.  This
frequently happens when the SMB client is under heavy load.  Previous to
1.4.1-rc5 the SMB server could not detect that a client had disappeared
and the smb virtual circuit along with all of the associated tree
connections, file handles and user authentications would be preserved
indefinitely.  This caused a problem for the re-connecting client
because when locking is enforced (even if only locally) the user would
be unable to open files that should no longer have been in use.

Second, it was discovered via access to Microsoft Crash Reports for
1.4.0 that there was at least one user laptop that was experiencing
afsd_service.exe panics due to an exhaustion of smb session and/or
smb network control blocks.  The number of Sessions and NCBs are a very
limited resource.  In the reported case, the sessions were being
allocated at a rapid rate and the SMB server did not realize that the
smb virtual circuits which were using the sessions were dead.   It
therefore became imperative that a mechanism for probing the validity of
smb virtual circuits be implemented as a part of 1.4.1.

Once code is added to detect the disconnects, it is necessary for the
server to actually cleanup the smb virtual circuits and associated data
structures.  Doing so requires that the reference counts, read/write
object locks, and mutex objects be managed appropriately in order to
avoid leaks, premature object destruction, and race conditions.

After cleaning up a majority of the reference leaks it was discovered
that actually counting the references correctly resulted in the
Integrated Login code breaking.  It turns out that the only reason that
 it was possible to obtain a token at login and then use it after the
user's logon session was created is because there were reference count
leaks.  Once the leaks were removed, the tokens which were set prior to
the creation of the logon session would immediately be discarded because
they were not being referenced by any logon sessions.

The reference counting was so bad in fact that I believe that the random
reports of users on Terminal Server systems losing their tokens was
caused by reference counts wrapping back to zero.  Windows Terminal
Servers are supposed to have very long up times.  This enabled several
counters to wrap especially given the lack of protection associated with
many of the global smb state variables and object queues.

I have done as much testing as I am capable of via automated testing.
Now I need some heavy users to deploy this code and push it.  Please
report back your findings.

Thanks.

Jeffrey Altman