Understanding DFSR debug logging (Part 10: File Conflicted between two Windows Server 2008)

In this scenario we will see a file that has been changed on two servers in between replication convergence and how that conflict resolution is replicated between servers. This is useful to understand in order to troubleshoot issues (or perception of issues that are actually expected behavior) leading to conflicts.  

 

(conflictwinner – Dfsr00001 – 2008.log and conflictloser – Dfsr00001 – 2008.log)

 

These are two Windows Server 2008 servers called 2008x86FSRV10 and 2008x86SRV11 in the contoso.com domain. The logs are from 2008x86FSRV10 (where the conflict is won) and from 2008x86SRV11 (where the conflict is lost). Both servers are participating in the TESTRG3 replication group for the TESTRF3 replicated folder. The file was called “confile.rtf”.  

 

<Upstream> 20080908 08:40:20.994 3104 USNC  2361 UsnConsumer::UpdateIdRecord LDB Updating ID Record: ß File modified and information being added to the DFSR database

+       fid                             0x400000000BA14 ß File ID for cross-reference purposes with USN journal

+       usn                             0x25f7898

+       uidVisible                      1

+       filtered                        0

+       journalWrapped                  0

+       slowRecoverCheck                0

+       pendingTombstone                0

+       internalUpdate                  0

+       dirtyShutdownMismatch           0

+       meetInstallUpdate               0

+       meetReanimated                  0

+       recUpdateTime                   20080908 15:31:45.162 GMT

+       present                         1

+       nameConflict                    0

+       attributes                      0x20 ß file, not folder

+       ghostedHeader                   0

+       data                            0

+       gvsn                            {5CB120DE-D2C2-452A-8280-B45FC155224F}-v15 ßversion is higher than UID so we know this file has been modified at least once (but remember that versions are not sequential for a file, they are sequential for the file server.)

+       uid                             {5CB120DE-D2C2-452A-8280-B45FC155224F}-v11 ß GUID matches between versions, so the file was created and last modified on this server

+       parent                          {009349B5-8677-4352-AC4F-13BCC111BAA0}-v1

+       fence                           16010101 00:00:00.000

+       clockDecrementedInDirtyShutdown 0

+       clock                           20080908 15:40:20.979 GMT (0x1c911c933ac2f01)

+       createTime                      20080908 15:31:45.131 GMT

+       csId                            {009349B5-8677-4352-AC4F-13BCC111BAA0}

+       hash                            00000000-00000000-00000000-00000000

+       similarity                      00000000-00000000-00000000-00000000

+       name                            confile.rtf ß file name is ‘confile.rtf’

+      

<Upstream> 20080908 08:40:20.994 3104 USNC  2364 UsnConsumer::UpdateIdRecord ID record updated from USN_RECORD: ß USN journal is updated at the same time to show a modification record (technically it happens before the DB update, this is a logging idiosyncrasy’)

+       USN_RECORD:

+       RecordLength:        88

+       MajorVersion:        2

+       MinorVersion:        0

+       FileRefNumber:       0x400000000BA14 ß note that FID’s match between USN and LDB debug log entries. We know this is the same file.

+       ParentFileRefNumber: 0x2100000000A77C

+       USN:                 0x25f7898

+       TimeStamp:           20080908 08:40:20.979 Pacific Standard Time

+       Reason:              Close Data Extend Data truncation ß reason code indicates the file has been modified (extend & truncate)

+       SourceInfo:          0x0

+       SecurityId:          0x0

+       FileAttributes:      0x20 ß file, not folder

+       FileNameLength:      22

+       FileNameOffset:      60

+       FileName:            confile.rtf ß same file name

+      

<Upstream>