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>
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