Revision Summary Date Revision History Revision Comments 3/2/2007 1.0 New Version 1.0 release 4/3/2007 1.1 Minor Version 1.1 release 5/11/2007 1.2 Minor Version 1.2 release 6/1/2007 1.2.1 Editorial Changed language and formatting in the technical content. 7/3/2007 1.2.2 Editorial Changed language and formatting in the technical content. 8/10/2007 1.2.3 Editorial Changed language and formatting in the technical content. 9/28/2007 1.2.4 Editorial Changed language and formatting in the technical content. 10/23/2007 1.3 Minor Updated to use data types in MS-DTYP. 1/25/2008 1.3.1 Editorial Changed language and formatting in the technical content. 3/14/2008 2.0 Updated and revised the technical content.
6/20/2008 3.0 Major Updated and revised the technical content. 7/25/2008 3.0.1 Editorial Changed language and formatting in the technical content. 8/29/2008 4.0 Major Updated and revised the technical content. 10/24/2008 5.0 Major Updated and revised the technical content. 12/5/2008 6.0 Major Updated and revised the technical content. 1/16/2009 7.0 Major Updated and revised the technical content. 2/27/2009 8.0 Major Updated and revised the technical content. 4/10/2009 9.0 Updated and revised the technical content. 5/22/2009 10.0 Major Updated and revised the technical content. 7/2/2009 10.1 Minor Clarified the meaning of the technical content.
8/14/2009 10.1.1 Editorial Changed language and formatting in the technical content. 9/25/2009 10.2 Minor Clarified the meaning of the technical content. 11/6/2009 10.2.1 Editorial Changed language and formatting in the technical content. 12/18/2009 10.2.2 Editorial Changed language and formatting in the technical content. 1/29/2010 11.0 Major Updated and revised the technical content. 3/12/2010 12.0 Major Updated and revised the technical content. 4/23/2010 13.0 Major Updated and revised the technical content. 6/4/2010 13.0.1 Editorial Changed language and formatting in the technical content. 7/16/2010 13.0.1 None No changes to the meaning, language, or formatting
of the technical content. 8/27/2010 14.0 Major Updated and revised the technical content. 10/8/2010 15.0 Major Updated and revised the technical content. 11/19/2010 16.0 Updated and revised the technical content. 1/7/2011 16.0 None No changes to the meaning, language, or formatting of the technical content. 2/11/2011 16.0 None No changes to the meaning, language, or formatting of the technical content. 3/25/2011 16.0 None No changes to the meaning, language, or formatting of the technical content. 5/6/2011 16.0 None No changes to the meaning, language, or formatting of the technical content.
the technical content. 2/13/2014 22.0 Updated and revised the technical content. 5/15/2014 23.0 Major Updated and revised the technical content. 6/30/2015 24.0 Major Significantly changed the technical content. 10/16/2015 25.0 Major Significantly changed the technical content. 7/14/2016 26.0 Major Significantly changed the technical content. 6/1/2017 26.0 None No changes to the meaning, language, or formatting of the technical content. 9/15/2017 27.0 Significantly changed the technical content. 12/1/2017 27.0 None No changes to the meaning, language, or formatting of the technical content.
FRS_UPDATE_FLAG_GHOSTED_HEADER #define FRS_UPDATE_FLAG_GHOSTED_HEADER (0x04) The update request is for ghosted header only. A ghosted header consists of the portion of a file data that excludes the main data stream. Section specifies the required format of the data stream transmitted by DFS-R. In this context, specifies the format of the backup data stream, which is part of the transmitted data stream. The main data stream is composed of bytes identified by the DATA stream ID, as specified in [MS-BKUP]. Notice that hexadecimal notation for flags is used. Flags can be combined using the bitwise OR operation. FRS_UPDATE_FLAG_DATA #define FRS_UPDATE_FLAG_DATA (0x08) The update request is for file data only. TRUE #define TRUE 1 The truth value TRUE. In DFS-R Booleans are of type long. FALSE #define FALSE 0 The value FALSE. FRS_UPDATE_FLAG_CLOCK_DECREMENTED #define FRS_UPDATE_FLAG_CLOCK_DECREMENTED (0x10) The presence of this bitmask value in an structure's flags field indicates that the update is the result of a dirty shutdown on the remote partner, and the clock has been decremented by the remote partner. The client MAY assign a new when installing an update with that flag. FRS_XPRESS_FILE_HEADER_SIZE #define FRS_XPRESS_FILE_HEADER_SIZE (0x4) The size of the FileHeader, as specified in section . XPRESS_RDC_MIN_GET_DATA_BUFFER_SIZE #define XPRESS_RDC_MIN_GET_DATA_BUFFER_SIZE (0x2410) The minimum size of the buffer required to hold the fragment headers, the block header, and one compressed block, as specified in section .
Concurrent Updates and Tombstones Machines can update different content concurrently, and synchronization propagates such changes seamlessly when are no conflicts. For instance, A could modify a, and B could delete b. Figure 13: Database contents of machine A and machine B, showing tombstone on machine B As usual, a session with A as server starts by A sending the updated to B. A session with B as server starts with B sending its version chain vector to A. B can take advantage of knowing that A knows at least {A 2} by sending a smaller version chain vector. In general, B sends its entire version chain vector. Figure 14: Version chain vector exchange between machine A and machine B The machines now exchange updates based on the version chain vectors. Figure 15: File replication sequence, showing tombstone replication Data for a is naturally not transmitted. The content on the two machines is then reconciled after synchronization. Figure 16: Database contents of machine A and machine B after replication, showing tombstone on machine A Directory Moves FRS associates with resources. They identify resources irrespective of their names or location in the File Replication Store. A replicated directory p, for instance, can be renamed to q, while a child gets created under p on a different machine without encountering a conflict. FRS furthermore associates a with each record to summarize the content on disk. File transmission is redundant if the hash is unchanged between different versions. The hash obviously changes in unpredictable ways when small changes are made to files. The implementation of FRS-2 uses to minimize network overhead on small file changes. In the following example, the content of directory p did not change when it was renamed to q. The record, therefore, still has the old hash for p—namely, 42. Consequently, only A needs to request content for b from B. Figure 17: Example of "directory move" file replication sequence between machine A and machine B Name Conflicts If two machines create files with the same names, they will have a different to distinguish them as name conflicting files. Machines handle name conflicts by creating a for the name conflict loser. Whether the tombstone also requires deleting content immediately depends on where the name conflict is detected. The same name conflict can also be detected on multiple machines. Each machine then generates a tombstone for the loser but in the end, only one tombstone prevails in the final .
Index A Abstract data model client ( 42, 82) server ( 42, 50) 102 102 25 15 AsyncPoll ( 60, 90, 101) 101 90 60 17 B 102 17 25 C 15 126 52 52 Client abstract data ( 42, 82) 101 90 88 88 88 94 initialization ( 50, 87) 94 local events ( 50, 101) message processing ( 50, 88) overview ( 41, 79) 95 96 96 98 99 97 97 99 91 89 sequencing rules ( 50, 88) timer events ( 50, 101) timers ( 50, 87) 100 76 38 104 19 19 19 19 19 18 18 19 19 18 18 19 111 18 73 D Data - abstract client ( 42, 82) server ( 42, 50) Data types 25 18 21 24 105 32 88 88 94 E 32 21 25 EstablishConnection ( 53, 88) 88 53 82 EstablishSession ( 55, 88) 88 55 Events 101 79 101 78 Examples 102 102 104 111 105 110 106 111 111 108 108 103 103 108 F
20 16 94 94 File transfer ( 86, 86) 31 31 30 30 18 25 24 24 25 25 26 26 24 30 30 29 29 28 28 29 29 29 29 28 28 24 23 23 26 26 27 27 20 20 25 25 51 114 G 8 111 I 114 113 113 12 Initialization client ( 50, 87) server ( 50, 51) InitializeFileTransferAsync ( 71, 94) 94 71 8 L Local events client ( 50, 101) server ( 50, 79) M 83 110 Message processing client ( 50, 88) server ( 50, 51) Messages 25 17 18 21 17 24 18 17 51 90 101 88 88 88 94 51 94 95 96 96 98 99 97 97 99 91 89 100 38 37 37 36 34 38 36 35 35 37 N 106 11 O 111 111 12 12 P
113 113 31 15 15 121 R 86 RawGetFileData ( 63, 95) 95 63 RawGetFileDataAsync ( 76, 96) 96 76 86 22 22 21 21 RdcClose ( 70, 96) 96 70 78 RdcGetFileData ( 67, 98) 98 67 99 77 RdcGetSignatures ( 64, 97) 97 64 RdcPushSourceNeeds ( 66, 97) 97 66 23 23 11 12 11 15 99 108 61 61 RequestUpdates ( 56, 91) 91 56 RequestVersionVector ( 58, 89) 89 108 58 S 32 Security 113 113 Sequencing rules client ( 50, 88) server ( 50, 51) Server abstract data model ( 42, 50) 51 initialization ( 50, 51) local events ( 50, 79) message processing ( 50, 51) 41 sequencing ( 50, 51) timer events ( 50, 78) timers ( 50, 51) 24 SlowSync ( 84, 99) 94 16 Syntax 25 18 21 18 24 T events client ( 50, 101) server ( 50, 78) Timers client ( 50, 87) server ( 50, 51) 126 17 21 21 20 U 111 22 22 22 22 UpdateCancel ( 62, 100) UpdateCancel method ( 62, 100) V 16 103 103 23 23 23 23 15 W 108 X 31 32