locked
Forum FAQ: Temporary files are not replicated by DFSR RRS feed

  • General discussion

  • Summary

     

    Someone may notice that DFS Replication (DFSR) is not replicating certain files even if most of the other files can be replicated successfully; the reason is that the temporary attribute is set on these un-replicated file.

     

    By design, DFSR does not replicate files if they have the temporary attribute set on them, and it cannot be configured to replicate it. The reason DFSR does not replicate files with the temporary attribute set is that they are considered short-lived files that you would never actually want to replicate. Using the temporary attribute on a file keeps that file in memory and saves on disk I/O. Therefore applications can use it on short-lived files to improve performance.

     

    Symptom

     

    Supposed you have setup DFS shares and DFS replication group between 2 or more DFS replication servers. Most of the content under the DFS target folder can be replicated to another DFS server; however, only a few of files cannot be replicated.

     

    When you use Fsutil to check the un-replicated file, you will see Temporary Attribute on the File.

    For example: Checking the Temporary Attribute on a File

    fsutil usn readdata c:\data\test.txt

     

    Major Version : 0x2
    Minor Version : 0x0
    FileRef# : 0x0021000000002350
    Parent FileRef# : 0x0003000000005f5e
    Usn : 0x000000004d431000
    Time Stamp : 0x0000000000000000 12:00:00 AM 1/1/1601
    Reason : 0x0
    Source Info : 0x0
    Security Id : 0x5fb
    File Attributes : 0x120
    File Name Length : 0x10
    File Name Offset : 0x3c
    FileName : test.txt

    File Attributes is a bitmask that indicates which attributes are set. In the above example, 0x120 indicates the temporary attribute is set because that is 0x100 and 0x20 (Archive) = 0x120.

    Here are the possible values:

    READONLY

    0x1

    HIDDEN

    0x2

    SYSTEM

    0x4

    DIRECTORY

    0x10

    ARCHIVE

    0x20

    DEVICE

    0x40

    NORMAL

    0x80

    TEMPORARY

    0x100

    SPARSE_FILE

    0x200

    REPARSE_POINT

    0x400

    COMPRESSED

    0x800

    OFFLINE

    0x1000

    NOT_CONTENT_INDEXED

    0x2000

    ENCRYPTED

    0x4000

     

    Resolution

     

    Removing the Temporary Attribute from Multiple Files with Powershell

     

    To remove the temporary attribute, we can use PowerShell which can be installed from here. After PowerShell is installed, please open Powershell prompt (Start, Run, Powershell or from the Programs menu) and run this command to remove the temporary attribute from all files in the specified directory, including subdirectories (in this example, D:\Data):

     

    Get-childitem D:\Data -recurse | ForEach-Object -process {if (($_.attributes -band 0x100) -eq 0x100) {$_.attributes = ($_.attributes -band 0xFEFF)}}

     

    Note: If you don’t want it to work against subdirectories just remove the -recurse parameter.

     

    More Information

     

    DFSR Does Not Replicate Temporary Files

    http://blogs.technet.com/askds/archive/2008/11/11/dfsr-does-not-replicate-temporary-files.aspx

     

    Applies to

     

    Windows Server 2008, Windows Server 2008 R2
    Monday, February 22, 2010 7:58 AM

All replies

  • This worked for me. Many thanks !
    Wednesday, May 2, 2012 3:12 PM
  • Good stuff (although I've not tried it yet).

    However, while I'm cool with the fact that DFS doesn't replicate temporary files, what I'd like to know is WHY some files get marked as temporary in the first place.

    .TMP files I can understand, but not .DOC, .PDF, .XLS files.

    Also, how to prevent this from happening in the first place, otherwise DFS is going to be much higher maintenance than it should be...

    Wednesday, October 3, 2012 11:58 AM
  • The reason I have found to cause this to happen is when files are sent through email as attachments. Outlook attaches the Temporary attribute and it stays when the user copies the files from the email to the network drive.
    Wednesday, October 10, 2018 10:46 PM