FRS has an internal database that contains all the files and folders it is replicating and each of these has a unique global ID (GUID). The database also contains a pointer to the last NTFS disk operation (in the USN Journal/NTFS Journal) that the FRS service processed.
If a user changes a file or folder on a disk, the following happens:
The operation is picked up by NTFS and an entry is made in the NTFS Journal
FRS monitors the NTFS Journal for changes and notes that a change has been made to that file
FRS keeps a record of the last NTFS Journal event that it processed and checks if it has processed it already
If it hasn’t processed it already, it looks at whether it is a file that it should replicate
If it should be replicated, the file goes into the normal process of staging, replicating, etc.
FRS increments the entry in its database about the NTFS Journal event that it has processed so it won’t consider it again
If there is a situation that the replication files has got few changes and the DC’s doesn’t communicate with each other because replications partners was shut down for a long time, FRS was not running or because of a communication failure in the network. When the communication is reestablished, FRS still knows the last NTFS Journal entry that it processed and it will compare this with the current NTFS Journal the next time it restarts.
The next time the FRS service starts, it sees that it has missed NTFS operations on the disk (It compares the its last processed NTFS operation and current NTFS journal database). This is when FRS complains it has reached a Journal Wrap state, the NTFS Journal log has wrapped around and it doesn’t know the current state of things on the disk.