If syncreplica -import determines that a packet is not applicable, it does not print the reason. Also, syncreplica -import uses different criteria than the lspacket command does to determine whether a packet is applicable. Therefore, lspacket may show that a packet is applicable even if syncreplica will not import it.

If a single version's cleartext is larger than the value specified for -maxsize, syncreplica creates the packet and prints a warning message. The -maxsize value is ignored for the packet creation; the packet is at least as large as the file and also includes header information.

When multiple imports occur simultaneously, the following error message may be displayed:

multitool: Error: Database identifier (dbid) not found in database: "VOB-tag".
...
op= mkhlink

This problem occurs when one update packet includes an operation that attempts to create a hyperlink and another packet includes an operation that removes an object at either end of the hyperlink.

Workaround: Retry the import. To prevent multiple simultaneous imports, use the sync_receive script.

When two or more imports occur simultaneously at a replica, the following error message may be displayed:

multitool: Error: Type manager "text_file_delta" failed delete_branches_versions operation

Workaround: Retry the import. To prevent multiple simultaneous imports, use the sync_receive script.

When a replica is restored using optimization (that is, it does not exchange packets with all other replicas in the VOB family), the special restorereplica oplog entry can be deleted prematurely at the replicas that exchanged updates with the restored replica. In order for all replicas in the VOB family to reflect the correct state of the restored replica, they all must receive the restorereplica oplog entry in an update packet.

For example, assume that replica evanston synchronizes daily with replica paris, paris synchronizes weekly with replica osaka, and osaka synchronizes monthly with evanston:

The administrator at evanston restores the replica from backup and enters the restorereplica command. Because evanston and paris exchange updates so frequently, the evanston administrator decides to optimize the restoration; after the update packet from paris is received and processed at evanston, the administrator enters the restorereplica -override command to complete restoration at evanston. At this point, the special restorereplica oplog entry is deleted at evanston, and the next time paris receives and processes an update packet, the oplog entry is deleted there. However, if paris does not send an update packet to osaka before deleting the oplog entry, osaka will have an inconsistent view of evanston's state.

The symptom of this problem is that the restored replica cannot import update packets sent from replicas that did not receive the restorereplica oplog entry. Imports fail with messages like the following:

multitool: Error: Replica incarnation for "evanston" is old: 12/31/69 19:00:00, should be 09/08/97 15:15:41
multitool: Error: Cannot apply sync. packet

If this problem occurs, contact Customer Support.

When you use syncreplica -import -receive -sclass to import only packets associated with a specific storage class, syncreplica also processes packets in the default storage bay.

Workaround: Use the sync_receive script to import packets.

If the export phase of a mkreplica command is interrupted and the replica-creation packet is not transferred to the new site, the packet is not deleted.

Workaround: Remove the packet and enter the mkreplica -export command again.

When you remove a replica, the rmreplica command renames the replica object. However, the rename operation is not recorded in the operation log, so migration-mode replicas do not rename the replica object automatically. Replicas not in migration mode rename the replica when they replay the rmreplica oplog entry.

Workaround: Explicitly rename the removed replica. For example, if a replica named natick was removed:

multitool rename replica:natick.deleted natick.deleted.old 

If a syncreplica -import command fails with a message like multitool: Error: Read from input stream failed: No such file or directory, the packet is corrupted.

Workaround: Delete the packet, ask the administrator at the sending site to re-create the packet and send it again, and then import it.

Using lsepoch and chepoch to recover a lost packet does not work if that packet included both a mkreplica operation and oplogs from that new replica. The reason is that the lsepoch output (at the replica that did not receive the packet) will not contain any information about the new replica, and the chepoch command at the sending replica modifies the epoch table according to the information in the lsepoch output.

For example:

The chepoch command does not reset the column for Replica C to zero. Therefore, Replica A's epoch table incorrectly shows that Replica B received the mkreplica operation for Replica C and all the work Replica C has done.

Workaround: Reset the epoch numbers manually. For example:

multitool chepoch -force B A=586 B=985 C=0 
Epoch row successfully set.

If a VOB is locked and there is an exception list (that is, the -nusers option was used), syncreplica -import ignores the lock.

An automatically generated comment for a directory checkout is not replicated in the following situation:

When you enter a lscheckout -areplicas command at the sibling replica, the comment generated in Step is listed, but the comment generated in Step is not.

When syncreplica --import reports that a packet cannot be imported because it depends on changes not yet received, the message may include one or more lines like the following:

This information may not be correct; the VOB may have more than 0 operations from the specified replica.

When a request for mastership of a branch type fails because requests are denied for one of more instances of the type, the error message says:

This message should say: