Windows: clear mountPointStringp on status change

If the data version of the cm_scache_t changes, we must clear
the mountPointString.  Otherwise, if the object is a mountpoint
or symlink, cm_HandleLink() will not attempt to build the new
target string.   The Windows CM never updates the contents of
a mountpoint or symlink.  It always destroys the old and creates
a new one.  However, the Unix CM simply updates the link data.
Apparently, the Windows clients have never noticed.

Reviewed-on: http://gerrit.openafs.org/3552
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: Jeffrey Altman <jaltman@openafs.org>
(cherry picked from commit bb4c0234b2fa5ae91097b6c40cbfda6ed7484eb0)

Change-Id: Icabba0b9bb6a1484d3ee3bc21dc6a39343e5491c
Reviewed-on: http://gerrit.openafs.org/3803
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

diff --git a/src/WINNT/afsd/cm_scache.c b/src/WINNT/afsd/cm_scache.c
index 755cd9c38e74a93bcb3251eb714b158bf592c853..9cb715b4df2229e42dacb2341b501e286f7d1fd0 100644 (file)
--- a/src/WINNT/afsd/cm_scache.c
+++ b/src/WINNT/afsd/cm_scache.c
@@ -1744,6 +1744,15 @@ void cm_MergeStatus(cm_scache_t *dscp,
         lock_ReleaseWrite(&buf_globalLock);
     }
 
+    /*
+     * If the dataVersion has changed, the mountPointStringp must be cleared
+     * in order to force a re-evaluation by cm_HandleLink().  The Windows CM
+     * does not update a mountpoint or symlink by altering the contents of
+     * the file data; but the Unix CM does.
+     */
+    if (scp->dataVersion != dataVersion)
+        scp->mountPointStringp[0] = '\0';
+
     /* We maintain a range of buffer dataVersion values which are considered 
      * valid.  This avoids the need to update the dataVersion on each buffer
      * object during an uncontested storeData operation.  As a result this