From bb4c0234b2fa5ae91097b6c40cbfda6ed7484eb0 Mon Sep 17 00:00:00 2001 From: Jeffrey Altman Date: Mon, 20 Dec 2010 09:59:43 -0500 Subject: [PATCH] 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 Tested-by: Jeffrey Altman --- src/WINNT/afsd/cm_scache.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/WINNT/afsd/cm_scache.c b/src/WINNT/afsd/cm_scache.c index ac2cb7d63d..e8469177f1 100644 --- 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