Microsoft Sync Framework (MSF) primer Six-file (folder) synchronization

In the first five articles, the sync for ado.net Service is introduced, starting with this article, which will begin with information about using MSF for file (folder) synchronization. Because the application of file synchronization is very wide, so it can be used to introduce 3-4 articles. Let's start today by introducing the principles of MSF file synchronization and using the existing classes in MSF to implement a simple demo (this demo supports files and folders) synchronization.

OK, let's start today's text.

Syncservices can help your application synchronize files, folders, and subfolders in NTFS, FAT, or SMB file systems. The directory you want to sync can be local or remote, and you do not have to belong to one file system. Applications can use static filters to exclude or include files by explicitly listing them or using wildcards such as *.txt, or the application can set up filters to exclude entire subfolders. Applications can also register to receive notification of the progress of file synchronization.

First, we need to understand the rationale for MSF's synchronization. In other words, what is the underlying implementation mechanism for file synchronization?

As described in the MSF SDK (built-in change detection algorithms for detecting changes to files and folders in the synchronization scope):

The MSF file Synchronization Service makes the so-called "report changes" when the following properties are changed:

1. The last time the file was modified.

2. If the hash operation is enabled, it is the hash value computed for the file. (about calculating the hash value of change detection: If the application specifies the COMPAREFILESTREAMS flag (for managed code) or the Filesync_init_flag_use_hashing flag (for unmanaged code) when the provider is initialized. The provider calculates the hash value for each file using all the contents of the file stream. The provider then compares the hash values, which makes change detection more accurate, but degrades performance slightly. This setup item will not be used in this demo)

3. File size.

4. File or folder name. This check is case sensitive.

5. Any file properties processed by the provider.

If the file is found to have the same creation time, size, and hash value as the previously understood file (if a hash is used), but the file name or path is different, the report file is moved or renamed. If multiple files are found to meet these criteria, Syncservices will consider the original file deleted and a new file created.

Syncservices to move or rename a folder as if the old folder was deleted and a new folder was created. Reports that the files in this folder have been moved. Therefore, in this case, you usually do not have to resend the file data.

This is the "proof" on which file synchronization is based (that is, what explains what the current file was modified and where it was modified)