Defines filters that can be used to include or exclude files and folders from the static synchronization scope.
Assembly: Microsoft.Synchronization.Files (in Microsoft.Synchronization.Files.dll)
Thetype exposes the following members.
|FileSyncScopeFilter()||Initializes a new instance of the class that has empty values for all filters.|
|FileSyncScopeFilter(IEnumerable<String>, IEnumerable<String>, FileAttributes, IEnumerable<String>)||Initializes a new instance of the class that is based on a list of files to exclude, a list of subdirectories to exclude, an attribute mask to use to exclude files and folders, and a list of file names to explicitly include.|
|AttributeExcludeMask||Gets or sets the attributes that are used to exclude files and folders from the scope.|
|FileNameExcludes||Gets the collection of file names to exclude from the scope.|
|FileNameIncludes||Gets the collection of file names to explicitly include in the scope.|
|SubdirectoryExcludes||Gets the collection of relative paths of directories to exclude from the scope.|
The static filters are evaluated on change detection and are applied equally to all items in the synchronization scope. For an item to be included in the synchronization, it must pass all static filters. For example, if a file is both explicitly excluded and explicitly included, the file will be excluded from the scope.
The same scope filter should be used on all providers in a synchronization community. If not, unwanted behavior might occur.
The filter that is passed to is used to initialize the provider object based on the scope filter when it is passed in. Subsequent changes to the filter will not affect the scope filter that is used by that instance of the provider. To change the scope filter that is used, you must create a new file synchronization provider object.
Changing the scope of a replica after the first synchronization can cause unintended side effects. For example, suppose sometime after the first synchronization you change the scope on replica A to start excluding *.txt. This will cause all files that have a .txt extension to be treated by replica A as deleted. No files will actually be deleted from replica A. However, metadata for A will contain tombstones for .txt files, and A will send delete changes to other replicas for the .txt files. If you also exclude *.txt on replica B, there is no effect, because B will filter changes from A that pertain to .txt files. However, if replica B does not change its filter, the deleted files will flow to it, be treated as real change requests, and be deleted from replica B.