I created a new ClearCase view on a Linux machine. And it was synchronized into the Windows machine where the developers work. However, I found that the permissions for the
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:
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.
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.
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