FIXES 22317
it seems like this might be a bug in solaris10 when handling contracts
of exiting chilren who have created kernel threads. the rxlistener is
a kernel thread on solaris and the child that starts the kernel_thread
returns and exits.
let's revert and try this again
====================
This delta was composed from multiple commits as part of the CVS->Git migration.
The checkin message with each commit was inconsistent.
The following are the additional commit messages.
====================
try this again
====================
try this again
incorporating STABLE14-macos104-20051005 STABLE14-macos-cleanup-20051006 macos-cleanup-20051006 macos-cleanup-20051007 from the 1.4.x branch, which needed to be forward-ported to work here, sadly.
There was a race condition associated with maintaining the
CM_FILELOCK_FLAG_CLIENTONLY flag on locks bound to scache entries
for Read Only volumes. Therefore, we remove the use of the flag
and simply test the RO status of the scache entry.
perhaps this should never be pulled up.
anyway, implement dentry cache status dumping for linux. and provide a tool to dump it
disabled (tool, not rpc) by default
====================
This delta was composed from multiple commits as part of the CVS->Git migration.
The checkin message with each commit was inconsistent.
The following are the additional commit messages.
====================
perhaps this should never be pulled up.
anyway, implement dentry cache status dumping for linux.^? and provide a tool to
dump it
disabled (tool, not rpc) by default
====================
perhaps this should never be pulled up.
anyway, implement dentry cache status dumping for linux.^? and provide a tool to
dump it
disabled (tool, not rpc) by default
Discovered a failure in the state machine. There was no method of
distinguishing between all servers being Down (which is handled by the
background thread) and all volumes being offline (perhaps due to a move).
Do not mark locks lost simply because the ExtendLock failed.
A lock is only lost if the server responds with EINVAL indicating
that the lock no longer exists. A lock can be renewed by other clients
that are also using the file. The client can make no assumptions about
the status of a lock based upon the passage of time.
As the file name of the OpenAFS installer changes with each release,
so must the Product ID (but not the Upgrade ID). Therefore, do not
hard code the Product ID in the Makefile, instead auto-generate it
as part of the installer.
