Fix CacheFetchProc in cases where the fileserver hates us
authorSimon Wilkinson <sxw@inf.ed.ac.uk>
Thu, 24 Sep 2009 23:27:40 +0000 (00:27 +0100)
committerDerrick Brashear <shadow|account-1000005@unknown>
Fri, 25 Sep 2009 06:05:39 +0000 (23:05 -0700)
commitf6f9ee5402f1718f330a00ec89fb34b05c3cd360
tree4d6c8fd9bb685fe8f70f8969b6bb781cb9138192
parent29ee678f3ab051a27cae46b02a0d42e0958a6bc8
Fix CacheFetchProc in cases where the fileserver hates us

In some situations, the fileserver returns a large negative number
as the length in an FetchData64 call. The old FetchProc code used an int32
to hold this number, and checked length > 0 before attempting to read more
data. The new code uses a uint32, and does while (length), which causes the
cache manage to loop until RX aborts the connection.

This patch restores the old behaviour. length becomes a signed int once more
(and the original 32 bit length from the wire is used, rather than truncating
the 64 bit value), and the conditional checks for > 0.

Reviewed-on: http://gerrit.openafs.org/493
Tested-by: Derrick Brashear <shadow@dementia.org>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
src/afs/afs_fetchstore.c