When the client changes IP addresses, in order to obtain optimal
performance it must:
(1) force the replacement of all existing rx connections
(2) ping all up and down servers
(cherry picked from commit 66596cc677e8cbf7fa40ad2962ccc4547692afb5)
another place where dotted notation and port numbers were not being used
in log output.
(cherry picked from commit ada9819fd630f6cbe6fb8d442e79326df1fcdcad)
log whenever a client host does not have an hcps value.
log the host by dotted ip-addr and port number
(cherry picked from commit ea3ed375e8f706456afddd23bff5ebf906565d92)
The old StoreData RPC is only supposed to be valid for files
smaller than 2GB. When StoreData64 was added, StoreData and StoreData64
were implemented as calls to common_StoreData64. This removed the bounds
checking on the old StoreData RPC making it possible for operations
beyond two 2GB to be requested even if the file server cannot support
them. This patch adds a validity check to ensure that the requested
file operations remain below 2GB. Failures return E2BIG.
(cherry picked from commit 9817af2a81eded29eeefcf8ef4445301a7d348ea)
A number of crash reports have been filed with Microsoft in afspthread.dll.
The crashes are occuring as the processes are terminating. In order to
attempt to address this problem this patch adds support for a DllMain()
entry point that is used to cleanup Thread Local Storage and the various
RX queues. One theory is that processes are loading and unloading DLLs
that are linked to afspthread.dll leaving the pthread data in a very
inconsistent state after each unload. By cleaning up the static data
during the unload, if afspthread is loading again it will be forced to
initialize the data once again.
(cherry picked from commit edff1e8788a2cadfd6bb9e08f9cfdbfb491924a6)
FIXES 31202
Remember to perform an OemToChar() conversion of the file name being
queried in Trans2QueryFileInfo
(cherry picked from commit 97a9d1964347e2b4b0f75e749b4d8f36d09fc876)
This patch fixes:
* race conditions around cm_Lock() calls that were not protected
by cm_SyncOp(LOCK) [asanka@secure-endpoints.com]
* deadlocks caused by obtaining smb_fid_t->mx after cm_scache_t->mx
* removes an extra Release smb_fid_t->mx that could result in
releasing a mutex that is not currently held
* changes the log representation of several return codes and fids to
be consistent with other output
(cherry picked from commit bf7404c3510d63b90c2cb15766f8455f79da90fe)
This patch adds code to perform return code error checking for all calls
to the ReadXyz() routines. If the rx connection was lost or if the dump
format being parsed was incorrect there was an opportunity for data to
the processed after an error had already been detected. In the best case
this would have simply resulted in additional work being performed when
it was not necessary but there was also the potential for modifying return
values which would later be used as input to later operations. Better
to simply catch the error when it initially occurs and be done with it.
The ReadString() function had the potential to write into one byte prior
to the start of the input array.
ProcessIndex() would not properly close Fdhandle nor the StreamHandle
if an error was detected.
RestoreVolume() had a problem with the processing of incremental dumps.
Originally AFS supported a concept of incrementals dumps which when
restored would simply add their contents to the existing volume. One
of the distinctions between the incremental and full dumps is that full
dump processing is responsible for removing any vnode entries from the
volume that are not present in the dump file headers. When the incremental
dump support was removed, the RestoreVolume() function was broken. If
a dump file contains multiple Dump Headers, then only the vnode entries
in the first Dump Header would be marked as being restored. Any vnode
entries restored from subsequent Dump Headers would be deleted when the
RestoreVolume() function reached the end. By removing the assignment
of 'tdelo = -1' within the loop that processes the Dump Headers, this
bug is resolved. Although RestoreVolume is only called with the
'incremental' parameter == 0 at the current time, the check for non-zero
values is restored and the "remove unrestored vnodes" functionality is
disabled when a non-zero value is provided.
The ReadVnodes() function did not perform error checking.
(cherry picked from commit 8074632d6938e965d3f02cc07359d85276c25dbc)
The 'active_vcp' variable is no longer being used for any useful
purpose and is the center of a race condition that could lead to
an undercount of references to 'vcp' objects. Remove it.
(cherry picked from commit f1ef60c020feffb73b2aee4c1871afba039afb67)
as pointed out by cg2v@andrew.cmu.edu the addition of performance
collection data for the GetCapabilities RPC broke backward compatibility
with previous builds because it altered the size of the data structure
sent on the wire.
Instead we count the number of GetCapabilties calls but do not gather
performance timing data as this can be done using spare fields.
(cherry picked from commit 78bb852509767ff32547c8dc90c385a4c503e0f9)
don't prevent all calls to getvolstatus, just the ones that are
not AFS pioctl calls.
(cherry picked from commit 632d0c701b31877b4d74f5f3849a5a8054f7326a)
An undercount has been detected of the smb_vc_t objects stored
in the smb_allVCsp list. Unfortunately, we have yet to be able
to find the cause of the undercount so this patch adds logic to
protect against the side effects until such time as the cause
can be identified.
(cherry picked from commit b9f22f0b7b9bf9aa746d3ef8ea63465b1cdadb97)
SYNOPSIS was mislabelled DESCRIPTION and the man page was therefore missing
the HTML formatting fixes.
(cherry picked from commit 5f70d9bb3ce0d1bb5db6604a53c52f483449e0d3)
On non-Windows use %llu for 64 bit printf.
Thanks to Brent Graveland for pointing this out.
(cherry picked from commit d3f9842bd4897b1b5c580858c3cb17326900548c)
update to make sure we have a cellservdb, that we shut down afs before an upgrade, and install the universal binary build script
(cherry picked from commit bb96daf441402cb6def2c20cc20f51d3d160b6e1)