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/hcl/ccm/versionvault/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.