Re-synchronizing after changing permission to view in ClearCase

爱⌒轻易说出口 提交于 2019-12-01 13:07:58

I have never changed permission on the filesystem itself (in your case, the vws view storage root folder)

If a cleartool desc -l -full -pro aview gives the wrong group, I would use fix_prot, as illustrated here.

alias sfp sudo /usr/atria/etc/utils/fix_prot

sfp -force -rec -chown <owner> -chgrp <ClearCaseUsers> -chmod 775 /path/to/viewStorage/yourView.vws
sfp -force -root -chown <owner> -chgrp <ClearCaseUsers> /path/to/viewStorage/yourView.vws

On a Windows client, I would typically do:

set CLEARCASE_PRIMARY_GROUP=aGroup
doskey fp=c:\Rational\ClearCase\etc\utils\fix_prot.exe -force -chgrp "aGroup" -chown aLogin $*
fp -rec -chmod 775 \\UNC\Path\to\view.vws
fp -root \\UNC\Path\to\view.vws

Using fix_prot in this fashion (without -root) is likely not going to cause issues, but absolutely do not use fix_prot -root to reprotect a view unless there is no other choice to access its contents.

Views on unix run AS the view owner, views on Windows run impersonating the view owner. This information is stored in the .identity directory (Unix) or *.sd files (Windows). The -root option overwrites this information, which can render the view at best partially usable.

On to the questions:

  1. use the fix_prot as mentioned above, without the -root option. It will work without surprises. If you need to force a primary group before creating the view on UNix, try: newgrp {groupname} before creating the view.

  2. There is no need to resync after reprotecting the view as the group information is not in the registry. If you were to change the owner of the view, you would need to reregister it as the owner name IS in the ClearCase registry.

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!