Preservation mode
If two replicas preserve identities and permissions or permissions
only, the operating system-level permissions of their individual elements
are synchronized. However, synchronizing the VOB group lists of the replicas
is a manual task that you must perform using cleartool protectvob –add_group.
The syncreplica
–import command generates the following identities-related error messages:
Can't create object with group that is not in the VOB's group list
Can’t change to a group that is not in the VOB’s group list
These messages indicate that a group was added to the sending replica’s VOB group list, and someone created a new element in that group or reassigned an existing element to that group. Then, the change was sent to a replica whose VOB group list has not been updated.
These messages may also indicate that the sending replica or receiving replica (or both) were created incorrectly as identities- and permissions-preserving.
If the replicas are intended to be identities- and permissions-preserving,
follow these steps to recover from this kind of error:
- (If necessary) Set a view, change to a directory within the replica, and
reenter the syncreplica –import command.
This produces diagnostics that include pathnames within VOB directories. For
example:
elem_fstat= ino: 0; type: 2; mode: 0444; uid: 1037; gid: 20 . . name_p= "aux_util.c" nsdir_ver_oid= ed2549e2.97f411cd.b3c8.08:00:69:06:4d:f6 (/vobs/dev/src@@/main/ev2/CHECKEDOUT.572)
These lines indicate that the element’s pathname in the sending replica is /vobs/dev/src/aux_util.c. Note also that its group ID (GID) is 20.
- Use the cleartool protectvob command
to add the new group to your replica’s VOB group list:
cleartool protectvob –add_group 20 /vobstg/dev.vbs
- Reenter the syncreplica –import command.
Note: If the administrators at the sites of identities- and permissions-preserving
replicas have not informed one another of changes in the shared user/group
namespace, you may need to adjust the password and group databases before
entering the protectvob command.
If one or both of the replicas should not be identities- and permissions-preserving,
follow these steps:
- Use the multitool chreplica command
to change the receiving replica to permissions-preserving or nonpreserving.
multitool chreplica –npreserve boston_hub@/vobs/dev Updated replica information for "boston_hub".
- Import the packet.
multitool syncreplica –import –receive Applied sync. packet /opt/devops/clearcase/shipping/ms_ship/incoming/sync_sanfran_hub_ 18-Jan-02.16.54.14_386_1 to VOB /net/minuteman/vobstg/dev.vbs
- Change the status of the replicas.
- If the sending replica should be nonpreserving or permissions-preserving, change it.
- If you want to retain preservation of identities and permissions in the receiving replica, change it back to identities- and permissions-preserving.
- Export update packets from the sending and receiving replicas to all siblings.
To avoid this problem in the future, use the procedure described in the section Gathering identities information.