This article describes changes to the File Replication service (FRS) in a Windows 2000 post-Service Pack 3 (SP3) hotfix that improves the robustness of the service. You must install Windows 2000 SP3 before you install this hotfix. This hotfix includes multiple fixes.
Fixes in This Release
- Vvjoins are stopped because of a missing parent. You see a "V: ERROR - Can't find parent node" entry in the Ntfrs debug log.
Change orders can arrive at a member out of order. This means that a member can receive a change order to create a child file or folder before the member receives the change order to create the parent folder. Before this hotfix is installed, a downstream member does not process the child change order until it receives the parent change order. This might cause a hung connection.
If you try to promote a new domain controller or if you trigger a non authoritative restore, the process does not complete.
- Unnecessary Vvjoins are performed. You see the following entries in the Ntfrs debug log:
<OutLogSendCo: 2028: 3229: S4: 20:15:27> Ignoring; end-of-join guid invalid: DOMAIN SYSTEM VOLUME (SYSVOL SHARE)\ SAS22\ SAS22 -> MP5\ Regiment \ MP5$ During the join process, the upstream partner decides whether the downstream partner needs a Vvjoin. In Windows 2000 SP3, this decision is based on checking the last join time. The last join time is the last time that the two partners joined. If the last join time matches, a Vvjoin is not performed. Instead, the upstream partner continues to send the change orders from the outbound log. If the last join time does not match, the upstream partner forces the downstream partner to perform a Vvjoin. Because the last join time update on both the partners is not atomic, one of the partners might update the last join time, but the other partner might not update the last join time. If this occurs, the last join time may not be synchronized. The next time that these two partners join, the upstream partner detects a mismatched last join time and force the connection to perform a Vvjoin.
<SndCsCheckCxtion: 2008: 497: S4: 20:15:27> ++ SAS22: Join guid is INVALID.
<SndCsDispatchCommError: 2008: 575: S4: 20:15:27> Comm pkt in error 010f7450
<CommCompletionRoutine: 2008: 343: S4: 20:15:27> :SR: Cmd 01118f00, CxtG 1d0b073a, WS ERROR_OPERATION_ABORTED, To MP5.smartframe. Regiment.COM Len: (308) [SndComplete]
- Delete change orders are incorrectly stopped when child files are present. Empty folders are left in the replica set.
If the deletes are out of order and a downstream member receives the delete for a parent folder before it receives the delete for all its child files and folders, the member stops the delete. When all the change orders are completed, the downstream partner is left with an empty parent folder.
- Local change orders under a parent are marked as delete deferred.
When a parent folder is marked as delete deferred, it is removed from the folder filter table. This causes any local changes to its children to be skipped.
Glossary of Terms Used in This Article
Change Order (CO)
When a change is made to a file or folder on a replica member, the information about that change (such as the name of the file or the ID of the member) is used to construct a message that is called a "change order." The change order is sent to the member's outbound partners. If they decide to accept the change, the partners request the associated staging file. After installing the change on their individual replica tree, the partners propagate the change order to their outbound partners.
The file GUID identifies the file or folder. It is created and managed by the replication service. It, with the replication version number and event time, is stored in the File ID table in the FRS database. Corresponding files and folders across all replica-set members have the same file GUID.
File ID Table
This is a table in the FRS database that contains an entry with version and identity information for each file and folder in the replica tree.
File Replication Service
FRS is a multiple-threaded, multiple-master replication engine. Windows 2000-based domain controllers and servers use FRS to replicate system policies and logon scripts for client computers that are running Windows 2000 and earlier versions of Microsoft Windows. FRS can also replicate content between Windows 2000-based servers that host the same fault-tolerant Distributed File System (DFS) root or link replicas.
All objects in a replica tree have a unique ID assigned to them. In FRS, the NTFS file system Object ID attribute that contains a 16-byte GUID is used. The same object on all replica members has the same object ID. This permits unambiguous location information for the object by using the object's GUID and the corresponding parent GUID.
The immediate upstream and downstream partners of a replica member are referred to as its replication partners. Upstream partners are also referred to as inbound partners. Downstream partners are also referred to as outbound partners.
In FRS, two or more computers that are configured to replicate the contents of a file folder. The individual computers are referred to as replica members.
Update Sequence Number
The NTFS file system maintains a monotonically increasing sequence number for each volume that is called an update sequence number (USN). The USN is incremented every time a modification is made to a file on the volume.
This is a vector of USNs, with one entry per replica set member. All change orders carry the originator GUID of the originating member and the associated USN. As each replica-set member receives the update, it tracks the USN in a vector slot that is assigned to the originating member. This vector describes whether the replica tree is current with each member. The version vector is then used to filter updates from inbound partners that may have already been applied. The version vector is also delivered to the inbound partner when the two members join. When a new connection is created, the version vector is used to scan the File ID table for more recent updates that are not seen by the new outbound partner.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.