Blogs

The mysterious case of the non-replicating files

  • Comments 1
  • Likes

Our DFSR guru Rob Post recently helped a newsgroup customer troubleshoot why certain .jpg files would not replicate. The customer described the problem as:

  • The file does not get replicated when it is copied into a DFS replicated directory.
  • No errors are found in DFSR log files.
  • Changing the contents of the file in hex editor does not make a difference.
  • Increasing the size of the file in hex editor results in start of replication.
  • Copies made from this file do not replicate.
  • If I zip and unzip the file, the unzipped version will replicate
     

Rob asked the customer to check whether the file was generating an entry in the USN journal, which is required to trigger replication. The customer ran the fsutil usn readdata command and posted the results for two files, one that replicates and one that does not. Notice anything different about the results? This is an interesting puzzle, so I’d like to challenge our readers to find out why the file wasn’t replicating and post your guess in the comments. I'll post the answer next week.

Hint: Neither replication engine (DFS Replication or FRS) will replicate the File1.jpg below. 

File that failed to replicate:

D:\Data>fsutil usn readdata File1.JPG
Major Version    : 0x2
Minor Version    : 0x0
FileRef#         : 0x029d000000000b9e
Parent FileRef#  : 0x0002000000000b35
Usn              : 0x00000000001bccf0
Time Stamp       : 0x0000000000000000 12:00:00 AM 1/1/1601
Reason           : 0x0
Source Info      : 0x0
Security Id      : 0x106
File Attributes  : 0x120
File Name Length : 0x18
File Name Offset : 0x3c
FileName         : File1.JPG

Replicating file:

D:\Data>fsutil usn readdata Dir\File2.JPG
Major Version    : 0x2
Minor Version    : 0x0
FileRef#         : 0x0002000000000ba4
Parent FileRef#  : 0x0003000000000ba2
Usn              : 0x00000000001bdde8
Time Stamp       : 0x0000000000000000 12:00:00 AM 1/1/1601
Reason           : 0x0
Source Info      : 0x0
Security Id      : 0x106
File Attributes  : 0x20
File Name Length : 0x18
File Name Offset : 0x3c
FileName         : File2.JPG

So readers, why won't the first file replicate?

--Jill


 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • File1.JPG (failing): File Attributes &nbsp;: 0x120 <br>File2.JPG (working): File Attributes &nbsp;: 0x20 <br> <br>WinNT.h defines the following for file attributes: <br>#define FILE_ATTRIBUTE_ARCHIVE &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0x00000020 &nbsp; <br>#define FILE_ATTRIBUTE_TEMPORARY &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0x00000100 &nbsp; <br> <br>So the failing file has (FILE_ATTRIBUTE_ARCHIVE | FILE_ATTRIBUTE_TEMPORARY) while the working file has only (FILE_ATTRIBUTE_ARCHIVE). <br> <br>Per the documentation: <br>[<a rel="nofollow" target="_new" href="http://technet2.microsoft.com/WindowsServer/en/Library/1aa249c0-40f3-4974-b67f-e650b602415e1033.mspx">http://technet2.microsoft.com/WindowsServer/en/Library/1aa249c0-40f3-4974-b67f-e650b602415e1033.mspx</a>] <br>DFS Replication does not replicate the following types of files: <br>... <br>- Files on which the temporary attribute has been set. <br> <br>The fact that this file does not replicate is therefore by design.