DFS Replication and "temporary" files
Hello!
This is my first publication, I hope that in the future I will write often.
If something is wrong designed, correct, I will correct as necessary.
In this paper, I had to face an interesting feature of DFS Replication . And although the question itself is not new, many can fill the bumps on it.
So, we have a stable working environment in which DFS replications are successfully configured and working. A replication group has been created, all the necessary servers have been added to it, the topology is correct, the schedule too, everything is fine ... until one day the new files added to the replicated folder stop copying to remote servers.
')
For example, I made a test environment in which only two servers - LAB-DC1 and LAB-FS1 . Each of them has a folder C: \ DFSR , between which replication should take place.
We copy into the folder on LAB-DC1 two test files and see that only one has been replicated to the second server.
Why?
Because the DFS Replication mechanism is designed so that by design does not copy files that have the Temporary attribute set. Use the fsutil command and see which attributes both of our files have.
The file not-a-temporary-file.txt has attributes 0x20 :
The temporary-file.txt file has the attributes 0x120 :
It is very easy to decode these hexadecimal numbers. Each possible file attribute has its hexadecimal value. Here are all possible options:
This list shows that not-a-temporary-file.txt has only the “Archive” attribute, and temporary-file.txt has the “Archive” and “Temporary” attributes.
And all files for which “Temporary” is set will not be replicated using the DFS Replication mechanism.
It is very simple to remove this attribute from all attached files and folders using a small PowerShell script:
Remove the attribute and voila! Our "problem" temporary-file.txt file was successfully copied to a remote server:
Where "temporary" files come from in the network - history is silent. I came from somewhere. In order to experiment, you can set the “Temporary” attribute for the file with your hands. You can also use a simple PowerShell script for this:
That's all, I hope that this article will help someone else in solving problems related to the work of DFS Replication .
Finally, I want to say thanks to Craig Landis, who published a comprehensive article on this topic in his blog back in 2008.
This is my first publication, I hope that in the future I will write often.
If something is wrong designed, correct, I will correct as necessary.
In this paper, I had to face an interesting feature of DFS Replication . And although the question itself is not new, many can fill the bumps on it.
So, we have a stable working environment in which DFS replications are successfully configured and working. A replication group has been created, all the necessary servers have been added to it, the topology is correct, the schedule too, everything is fine ... until one day the new files added to the replicated folder stop copying to remote servers.
')
For example, I made a test environment in which only two servers - LAB-DC1 and LAB-FS1 . Each of them has a folder C: \ DFSR , between which replication should take place.
We copy into the folder on LAB-DC1 two test files and see that only one has been replicated to the second server.
Why?
Because the DFS Replication mechanism is designed so that by design does not copy files that have the Temporary attribute set. Use the fsutil command and see which attributes both of our files have.
The file not-a-temporary-file.txt has attributes 0x20 :
The temporary-file.txt file has the attributes 0x120 :
It is very easy to decode these hexadecimal numbers. Each possible file attribute has its hexadecimal value. Here are all possible options:
| 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 |
This list shows that not-a-temporary-file.txt has only the “Archive” attribute, and temporary-file.txt has the “Archive” and “Temporary” attributes.
And all files for which “Temporary” is set will not be replicated using the DFS Replication mechanism.
It is very simple to remove this attribute from all attached files and folders using a small PowerShell script:
Get-ChildItem C:\DFSR -recurse | ForEach-Object -process {if (($_.attributes -band 0x100) -eq 0x100) {$_.attributes = ($_.attributes -band 0xFEFF)}} Remove the attribute and voila! Our "problem" temporary-file.txt file was successfully copied to a remote server:
Where "temporary" files come from in the network - history is silent. I came from somewhere. In order to experiment, you can set the “Temporary” attribute for the file with your hands. You can also use a simple PowerShell script for this:
$file = Get-Item C:\DFSR\temporary-file.txt $file.Attributes = 0x120 That's all, I hope that this article will help someone else in solving problems related to the work of DFS Replication .
Finally, I want to say thanks to Craig Landis, who published a comprehensive article on this topic in his blog back in 2008.
Source: https://habr.com/ru/post/245075/
All Articles