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>
This commit is contained in:
Jeffrey Altman 2010-12-20 09:59:43 -05:00 committed by Jeffrey Altman
parent 27469e59b1
commit bb4c0234b2

View File

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