更新ClearCase快照视图时出现错误。

Question

我有一个用户（仅有的一个，其他用户都没问题）试图更新他们的ClearCase视图。
在过去的6个月里，这一直有效，但今天出了问题。

当他们尝试更新时，会收到以下错误信息：

Unable to read directory "."  Permission denied

Errors were encountered in loading "\VOB"

我进行了"gpresult"，看起来他们在正确的组中，流也没有被锁定。
CC Doctor 也没有出现任何错误。
自从上周五使用 CC 以来，没有发生任何已知变化。
还有其他地方我应该查看吗？
我想不出更多的想法，我相信我已经到了我的谷歌搜索的尽头...

- Rubasu

---

好的展示 - 这个问题展现了适当的研究和良好的 RTFM 技能。 - Pulak Agrawal

Answer 1

通常需要检查的元素包括：

• 环境变量CLEARCASE_PRIMARY_GROUP
• 视图的特性：

cleartool lsview -l -full -pro viewTag 

由于用户没有进行任何更改，可能与Windows配置文件有关。确保问题在重启后仍然存在。

还要确保没有Windows组策略更改或登录权限演变（例如撤销管理员权限），这可能解释为什么用户无法读取ClearCase快照视图的根目录。这可能是Windows ACL问题（即与ClearCase无直接关系）。

---

OP 报告称，ClearCase 不再考虑由 CLEARCASE_PRIMARY_GROUP 引用的组，因为该组不在用户注册的前 32 个 Windows 组中。

技术说明 "关于 CLEARCASE_GROUPS 变量" 详细介绍了正确的解决方法：

该变量用于解决ClearCase使用的SUNRPC协议中存在的一个限制。此限制指出，任何成员属于超过32个Microsoft Windows组（域或本地）的用户都可能遇到访问问题。如果对于任何用户存在用户环境变量CLEARCASE_GROUPS，则ClearCase将优先考虑该变量值中指定的以分号分隔的组列表以确定（或显示）用户所属的组。实质上，当您登录Windows时，会接收到一个访问令牌。ClearCase将按照Windows提供它们的顺序处理这些令牌（这是完全随机的，并且无法以任何方式进行配置）。一旦达到32个组，ClearCase将停止处理令牌。设置CLEARCASE_GROUPS变量是解决此行为的唯一方法。当设置该变量时，ClearCase将按照列表中的顺序检查CLEARCASE_GROUPS列表中每个组名，并将其与提供的Windows访问令牌进行比较。如果组名与Windows访问令牌中的某个组相匹配，则ClearCase将创建用于该组的ClearCase访问令牌。当变量用尽后，ClearCase将返回到Windows访问令牌列表，并从剩余列表中按照提供的顺序添加任何尚未添加到ClearCase令牌中的组，直到使用Windows令牌中的所有组（如果少于32个）或达到32组限制为止。

- VonC

---

同意VonC的观点 - Clearcase Windows根据您的Windows登录/域ID授予权限。由于它适用于所有其他用户并且您已经进行了基本的CC检查，因此重新启动（您看到的是Windows :)）并与系统管理员检查AD或网络上的任何Windows相关更改是有意义的。 - Pulak Agrawal

谢谢你们两个，但最终问题是出在用户组上。我不知道ClearCase只使用前32个列出的组来检查权限。我添加了一个"CLEARCASE_GROUPS" 用户环境变量，这样它就会首先使用这些组。 - Rubasu

@Rubasu 好的。我已经完成了关于该过程的文档答案。 - VonC