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.

Change-Id: If2297ed0a323411df13b7828d11dbb653669d351
Reviewed-on: http://gerrit.openafs.org/3552
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: Jeffrey Altman <jaltman@openafs.org>

diff --git a/src/WINNT/afsd/cm_scache.c b/src/WINNT/afsd/cm_scache.c
index ac2cb7d..e846917 100644 (file)
--- a/src/WINNT/afsd/cm_scache.c
+++ b/src/WINNT/afsd/cm_scache.c
@@ -1747,6 +1747,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