Resync is nearly identical to initialize, and can even be specified in lieu of initialize for directory replication contexts, with the following differences:
The replica directory is *not* required to be empty. Internally, the destination moves the existing files out of the way. (In 4.3 to 4.5 inclusive, this is by renaming these files to a $destdir/.ddrsaved/ directory. In 4.6+, it is by making a snapshot then deleting the files from the replication context $destdir.)
For each file in the source directory, we check if the same relative path exists on the destination (we check the $destdir/.ddrsaved, or the snapshot). If the file exists, we check if the destination file is identical to the source file. If it is identical, the existing replica file is hard linked into place with no further need to filter or send any of its content. The file identity check happens in constant time. The check succeeds if the replica file had been created by directory replication >= 4.3 or by collection replication of any vintage, I believe. Note that this implies that seeding can be accomplished by first doing collection replication (convenient if the Data Domains are in a LAN environment), then breaking collection replication, then doing directory replication resync.
If a replica file is not found or if its content does not match, the file is replicated like normal, i.e. it is filtered on a segment by segment basis. The whole point of resync is to avoid this filtering where possible. A potential pitfall is that human activity or application logic that renames files could cause the originator or replica files to be moved/renamed after replication was broken, prior to resync. This causes the pathname lookup in resync to find no match, and necessitates full filtering of each file. Since the segments will exist on the destination you will get high replication compression, but an opportunity is missed to avoid sending the segment references and filtering them in the first place.
Notes on resync with the Retention Lock feature:
In 4.5 resync fails if the replica has, or ever had, retention lock enabled.
In 4.6 and above there are some additional requirements related to retention-locked files on the replica. In essence, any retention-locked file on the destination must also exist and must have matching content and attributes on the originator. This is to prevent replication from attempting to remove retention-locked files on the replica.