Cross-domain file server bidirectional synchronization method and system based on file list

Abstract

The invention provides a cross-domain file server bidirectional synchronization method and system based on a file list, and relates to the technical field of data transmission, the method comprises the following steps: respectively generating a first file list and a second file list according to files in a first file server and a second file server; comparing the first file list with the second file list, marking files in the first file server and the second file server, and determining files needing to be synchronized to the opposite terminal; and executing a file synchronization process according to the mark. According to the invention, quick and accurate bidirectional synchronization of the files among the cross-domain file servers can be realized.

Description

Technical Field

[0001] The present invention relates to the technical field of data transmission, and in particular to a cross-domain file server bidirectional synchronization method and system based on a file list. Background Art

[0002] The hardware of the network security isolation and information one-way import and export system adopts the "front-end and back-end + dual one-way" mode, that is, it consists of a front-end server, a back-end server and two sets of one-way isolation transmission units. One set of one-way isolation transmission units is used as an import unit, and the other set of one-way isolation transmission units is used as an export unit. The one-way isolation transmission units are used to realize two sets of mutually reverse one-way data transmission functions, so that the two parties of data transmission are physically isolated, providing one-way loop-free security for data transmission while realizing file transmission.

[0003] The significance of bidirectional synchronization of cross-domain file servers is to ensure that the file contents between different file servers in different domains are always consistent. In the related art, for bidirectional synchronization between cross-domain file servers, two sets of single-guide systems can be deployed to achieve bidirectional synchronization between file servers through a dual-single-guide method. However, since the files are on both sides of the isolated network, it is impossible to compare the files by comparing the file contents to determine whether the files have changed. It can only be determined by comparing the last update time of the files. However, for the two sets of network isolated environments, it is difficult to ensure the time synchronization between the two. In addition, the file transfer time is relatively long. After a file is transferred from one end to the other, the transferred file may be judged as a new file and thus transferred back from the other end again, which leads to the problem that the file cannot be deleted due to repeated transmission. Summary of the invention

[0004] In order to solve the deficiencies of the prior art, the purpose of the present invention is to provide a method and system for bidirectional synchronization of cross-domain file servers based on a file list, which can achieve fast and accurate bidirectional synchronization of files between cross-domain file servers by introducing a file list.

[0005] To achieve the above object, according to some embodiments, a first aspect of the present invention provides a cross-domain file server bidirectional synchronization method based on a file list, comprising:

[0006] Generate a first file list and a second file list according to the files in the first file server and the second file server respectively;

[0007] Compare the first file list with the second file list, mark the files in the first file server and the second file server, and determine the files that need to be synchronized to the peer end;

[0008] The file synchronization process is executed according to the mark.

[0009] Preferably, the file list includes the file path, file name, file size, and the last update time of the file.

[0010] Preferably, comparing the first file list with the second file list, marking the files in the first file server and the second file server, and determining the files that need to be synchronized to the peer end, includes:

[0011] The first file server receives the second file list sent by the second file server, compares the received second file list with the generated first file list, marks the files in the first file server as the first mark (local), marks the files identical to those in the second file server as the second mark (send_ack), and marks the files that conflict with those in the second file server according to the file conflict strategy;

[0012] and / or,

[0013] The second file server receives the first file list sent by the first file server, compares the received first file list with the generated second file list, marks the files in the second file server as the first mark (local), marks the files that are the same as those in the first file server as the second mark (send_ack), and marks the files that conflict with those in the first file server according to the file conflict strategy.

[0014] Preferably, when the file conflict strategy is a later time priority strategy, the earlier time file in the conflict file is marked as the second mark (send_ack);

[0015] Alternatively, when the file conflict policy of one end of the first file server and the second file server is the local priority policy and the file conflict policy of the other end is the opposite side priority policy, the conflict file mark set to the opposite side priority policy is the second mark (send_ack).

[0016] Preferably, executing the file synchronization process according to the mark includes:

[0017] The first file server synchronization process specifically includes:

[0018] Compare the files in the first file server with the first file list, mark the added and / or changed files as a third mark (init), mark the reduced files as a fourth mark (del_mark), mark the received files with a fifth mark (receive) sent by the second file server as a first mark (local) and update them to the first file list;

[0019] Synchronize the file marked with the third mark (init) to the second file server, mark it with the sixth mark (send), and mark it with the second mark (send_ack) after receiving the message feedback from the second file server;

[0020] Sending a deletion instruction for the corresponding file to the second file server according to the fourth mark (del_mark), and marking it as a seventh mark (del_complete) after receiving a message feedback from the second file server;

[0021] and / or,

[0022] The second file server synchronization process specifically includes:

[0023] Compare the files in the second file server with the second file list, mark the added and / or changed files as a third mark (init), mark the reduced files as a fourth mark (del_mark), mark the received files with a fifth mark (receive) sent by the first file server as a first mark (local) and update them to the second file list;

[0024] Synchronize the file marked with the third mark (init) to the first file server, mark it with the sixth mark (send), and mark it with the second mark (send_ack) after receiving the message feedback from the first file server;

[0025] According to the fourth mark (del_mark), a deletion instruction for the corresponding file is sent to the first file server, and after receiving a message feedback from the first file server, it is marked as a seventh mark (del_complete).

[0026] Preferably, the first file server synchronization process further includes:

[0027] receiving a file synchronized by the second file server, and marking the received file as a fifth mark (receive);

[0028] Receive a deletion instruction sent by the second file server, delete the corresponding file in the first file server and mark it as a seventh mark (del_complete);

[0029] and / or,

[0030] The second file server synchronization process also includes:

[0031] receiving a file synchronized by the first file server, and marking the received file as a fifth mark (receive);

[0032] A deletion instruction sent by the first file server is received, and a corresponding file in the second file server is deleted and marked as a seventh mark (del_complete).

[0033] Preferably, the method further includes deleting the synchronization file and the corresponding mark of deleting the file.

[0034] Preferably, the method further includes determining whether the added and / or changed files are successfully written to the disk, and if successful, marking it as the third mark (init), otherwise marking it as the eighth mark (prepare).

[0035] A second aspect of the present invention provides a cross-domain file server bidirectional synchronization system based on a file list, comprising:

[0036] A file list generating module, configured to generate a first file list and a second file list according to files in the first file server and the second file server, respectively;

[0037] A comparison module is configured to compare the first file list and the second file list, mark the files in the first file server and the second file server, and determine the files that need to be synchronized to the peer end;

[0038] The synchronization module is configured to execute a file synchronization process according to the mark.

[0039] A third aspect of the present invention provides a cross-domain file server system, comprising a first file server and a second file server isolated from each other, wherein the first file server and the second file server can respectively implement unidirectional isolated transmission;

[0040] The first file server is configured to generate a first file list according to the files in the first file server; compare the first file list with the second file list received and sent by the second file server, mark the files in the first file server, determine the files that need to be synchronized with the second file server, and execute the file synchronization process;

[0041] The second file server is configured to generate a second file list based on the files in the second file server; compare the second file list with the first file list received and sent by the first file server, mark the files in the second file server, determine the files that need to be synchronized with the first file server, and execute the file synchronization process.

[0042] Compared with the prior art, the present invention has the following beneficial effects:

[0043] The present invention provides a cross-domain file server bidirectional synchronization method and system based on a file list, which realizes the real-time bidirectional synchronization function of files in a single-dual guide or network gate environment. The file list is introduced in the bidirectional synchronization process, and the incremental comparison of the files on the local side can be realized by using the file list on the local side to compare the files on the local side, so as to judge the real-time changes of the files on the local side; by comparing the file lists on both sides, the full comparison of the files on both sides can be realized, so as to accurately and quickly judge the differences between the files on both sides, and then guide the bidirectional synchronization of the files. By marking the files differently and executing the corresponding file processing flow according to the marks, the problem of repeated sending or inability to delete files in the bidirectional synchronization process is effectively solved.

[0044] Advantages of additional aspects of the present invention will be given in part in the following description, and in part will become obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] The accompanying drawings in the specification, which constitute a part of the present invention, are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations on the present invention.

[0046] Figure 1 is a schematic diagram of the method in Embodiment 1 of the present invention;

[0047] Figure 2 Schematic diagram of the file marking process in the first embodiment of the present invention;

[0048] Figure 3 This is a schematic diagram of a file synchronization process in Embodiment 1 of the present invention. DETAILED DESCRIPTION

[0049] The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0050] Embodiment 1

[0051] Embodiment 1 of the present invention, as Figure 1-Figure 3 As shown, a cross-domain file server bidirectional synchronization method based on a file list is provided, comprising:

[0052] Generate a first file list and a second file list according to the files in the first file server and the second file server respectively;

[0053] Compare the first file list with the second file list, mark the files in the first file server and the second file server, and determine the files that need to be synchronized to the peer end;

[0054] The file synchronization process is executed according to the mark.

[0055] For file communication between file servers in different domains (cross-domains), two sets of single-pipe systems need to be deployed respectively to achieve two-way communication in a dual-single-pipe mode. However, if two-way synchronization of files needs to be achieved on this basis, the following problems exist:

[0056] Since the files are on both sides of the isolated network, it is impossible to compare the files by comparing the file contents to determine whether the files have changed. Therefore, it is only possible to determine whether the files have changed by comparing the basic information of the files, such as the file size and the last update time of the file.

[0057] If you only judge whether a file needs to be synchronized based on the file size, you cannot know whether the file on the larger side needs to be synchronized to the smaller side, or the file on the smaller side needs to be synchronized to the larger side. Therefore, in general, you cannot judge whether a file needs to be synchronized based on the file size.

[0058] Therefore, we can only judge whether the file has changed based on the file time, and then synchronize the file. However, since the operating environment is two systems with network isolation, it is difficult to achieve different time in the two network isolated environments, and it is difficult to judge from which side the file is synchronized to the other side by comparing the last update time of the files on both sides. The strategy of judging whether the file has changed simply by time change can only be run on the same machine, and is not applicable to two network isolated environments.

[0059] The only way to determine file conflicts in two isolated network environments is to use a master-slave structure, that is, one end takes priority. At this time, if the files on both sides of the isolated network are completely consistent, you can determine which file is the latest update by judging the last update time of the files in the isolated network. However, as mentioned above, since two-way synchronization is performed in an isolated network environment, it is difficult to ensure time synchronization. In addition, the file transfer time is relatively long, and the following problems may occur in two-way synchronization:

[0060] If file A is synchronized from end a to end b, and the file that is written to the disk is file B, the modification time of file B will be later than that of file A. Therefore, if the time comparison shows that the time of file B is later than that of file A, plus the time delay during the synchronization transmission, the system will determine that file B needs to be synchronized to end a again. Therefore, it is impossible to determine whether the file has been modified due to time changes based on the information of the file itself. After the file is transferred from one end to the other, it may be transferred back from the other end again because it is a newly uploaded file.

[0061] Furthermore, because the above problem occurs repeatedly, when deleting file A, the same file B at the other end may also be sent to end A at the same time. This may cause the file to be unable to be deleted due to repeated transmission.

[0062] In addition, if the time on both sides is inconsistent, and the time on side A lags behind that on side B, when file A on side A changes, the last update time of the file changes, but the time after the change may also lag behind that of side B, resulting in a failure to synchronize. This type of file conflict caused by inconsistent files cannot be resolved.

[0063] Based on this, the embodiment of the present invention proposes to solve the above problems through a file list. The file list is a cache of the file information list obtained from the file server, including the file path, file name, file size, and the last update time of the file. By setting a policy and comparing the file lists on both sides, the file conflicts on both sides can be resolved. By comparing the file list with the local file, it is possible to accurately and quickly determine whether the file has changed.

[0064] In this embodiment, bidirectional synchronization needs to be implemented. It is assumed that the two isolated servers are the first file server and the second file server. Since the synchronization logic between the two file servers is the same, the following takes the first file server as the local end and the second file server as the opposite end as an example to illustrate the process of synchronization from the first file server to the second file server.

[0065] For a two-way synchronization task, when the task is just running, a file list (first file list) of this end (first file server) is generated and sent to the other end (second file server). At the same time, the file list (second file list) sent by the other end is received and compared, and the files on this end are marked as local, and the files that exist on the other end and this end are marked as send_ack. The marking of files is performed in the program of the file server, and the file server stores a data list of the corresponding side files, including the file path, name, size, and last update time, which is similar to the format of the file list. In order to distinguish the operations in the data list from the operations in the file list used for two-way synchronization, the operations marked in the data list are described as marking of files below, to distinguish them from the operations marked in the file list.

[0066] In this embodiment, send_ack refers to files that have been sent to the peer file server or are determined to exist on the peer file server, and the send_ack mark is used to determine whether the files on the file server at a certain moment have changed or increased compared to the last time; local refers to files that exist on the local file server, and the local mark is used to determine whether the files on the server at a certain moment have decreased compared to the files at the previous moment.

[0067] When a task is just running, mark the task as the prepare stage.

[0068] Query all files in the local file server, store them in the first file list, and then mark the task as the init stage.

[0069] The first file list is sent to the peer end, and then the task is marked as the send phase, waiting to receive the file list from the peer end.

[0070] If the file list of the other end is not received within a timeout period, all files in the local file server are queried again and the first file list is updated, the task is marked as the init stage, and the first file list is sent to the other end again, and the cycle repeats.

[0071] When the local end receives the second file list sent by the opposite end, different processing flows are executed according to the task stage in which the local end is located.

[0072] If the local task is to receive the file list from the other end, no processing is done.

[0073] If the local task is the init task when receiving the peer file list, the local file list is sent and the local task is marked as the send stage.

[0074] If the local task is in the send or complete stage when receiving the peer file list, the status of the same files on the peer and local ends will be marked as send_ack. Then the local task will be marked as complete.

[0075] Compare the file lists at both ends. If the file names and paths at both ends are the same, there is a file conflict. The file conflict can be resolved according to the file conflict strategy.

[0076] If it is determined that there is no conflict in the files and the files are identical, the files are marked as send_ack.

[0077] There are three file conflict resolution strategies:

[0078] Prioritize later times. This strategy is suitable for environments where the time of two domains is synchronized and the transmission time is small, as well as local file incremental comparison.

[0079] Local side priority: This policy is applicable to scenarios where local side priority is used. It can be used in pairs with the opposite side priority policy in different network domains.

[0080] Opposite-side priority: This policy is applicable to scenarios where peer-side priority is used. It can be used in pairs with the local-side priority policy in different network domains.

[0081] If the files at both ends conflict, and the policy of the local end is to give priority to the other side, the conflicting files do not need to be sent, and the files are marked as send_ack.

[0082] If the local policy is local priority, the file will be synchronized to the peer end without marking it as send_ack.

[0083] After the configuration is completed, the task is executed regularly to determine the task status. If the task status is completed, the file synchronization process is executed. When synchronizing files, duplicate synchronization files should be avoided, and duplicate deletion instructions should be avoided.

[0084] In the file synchronization process, first, clean up the response status of the last execution. Query the files marked as del_complete, and clear the corresponding temporary status (marks) generated when deleting files such as del_send and del_complete.

[0085] Query files whose file status is marked as send_ack, and clear temporary status (marks) generated when sending files such as send and init.

[0086] Then, query the local real-time file information on this end and compare it with the file list in the cache.

[0087] Compare the real-time file and the file cache to determine whether the file has been reduced or whether the peer file has been synchronized to the local end.

[0088] If the status of the local real-time file information in the cache is receive, mark the file as local.

[0089] If the local real-time file information exists in the file list, it will not be processed.

[0090] If the local real-time file lacks the corresponding file in the file list, it is judged that the file is reduced and is marked as del_mark.

[0091] Furthermore, the local real-time file information and the file list are compared to determine whether the files are added or changed, and the newly added or changed files are marked as init.

[0092] Compare the file with the file list. If there is a file that is not included in the file list, determine whether the file is successfully written to the disk. If it is successfully written to the disk, mark it as init, otherwise mark it as prepare.

[0093] If the file list contains the file and the file status is prepare, determine whether the file is successfully written to the disk. If so, mark it as init; otherwise, mark it as prepare.

[0094] If the file is marked as init, determine whether the file has been sent. If the file has been sent, delete the init mark.

[0095] If the file is not marked as send status, and is not marked as send_ack or receive status, determine whether the file has been updated based on the last modification time and file size. If updated, mark it as init status, otherwise delete the init mark.

[0096] Furthermore, files marked as del_mark are deleted synchronously.

[0097] Get the file whose status is del_mark, send a delete file instruction to the peer, and then mark the file as del_send.

[0098] After receiving the message feedback from the peer end regarding the file deletion instruction, the file is marked as del_complete status.

[0099] In this embodiment, del_mark: the file on the file server is reduced and marked as del_mark, and then the file deletion instruction will be sent to the other side according to this mark;

[0100] del_send: After the delete command is issued, the file is marked as del_send;

[0101] del_complete: After receiving the deletion instruction, the file server on the other side marks the deleted file as del_complete to prevent the server on this side from sending the file deletion instruction to the other side after detecting that the file has been deleted.

[0102] Afterwards, sync the files marked as init.

[0103] Get the file whose file status is init, send the file sending instruction to the peer end, mark the corresponding file as send status and send it to the peer end.

[0104] After receiving the message feedback that the command has been sent to the other end, it indicates that the file has been sent successfully and the file is marked as send_ack.

[0105] Repeat the above file synchronization process to achieve real-time synchronization of files.

[0106] Since the above judgments are all aimed at the changes of the files on the same end, and the time and size of the files are judged, without involving the files on the other end and without judging the file content, this judgment method is extremely fast compared to the method of comparing the changes in the file content on both sides, and can ensure real-time performance.

[0107] The local end and the remote end execute the above file synchronization process at the same time, so as to realize two-way synchronization of files.

[0108] During the file synchronization process, it is necessary to update the file status in time after uploading or deleting the file to avoid synchronizing the newly added files or deletion instructions back.

[0109] During synchronization between the local end and the peer end, for the file deletion instruction sent, the peer end receives the message feedback for the file deletion instruction. When the peer end completes the file deletion, the message feedback is sent, and then the local end marks the file as del_complete status.

[0110] For file synchronization, after the file upload is successful, the peer marks the received file as receive. The next time the file is found in the query list, it will be marked as local and will not be sent back.

[0111] After deleting a file, it is marked as del_complete. When the next query list is found to have fewer files, the deletion command will not be sent back because the file is marked as del_complete.

[0112] Embodiment 2

[0113] This embodiment provides a cross-domain file server bidirectional synchronization system based on a file list, including:

[0114] A file list generating module, configured to generate a first file list and a second file list according to files in the first file server and the second file server, respectively;

[0115] A comparison module is configured to compare the first file list and the second file list, mark the files in the first file server and the second file server, and determine the files that need to be synchronized to the peer end;

[0116] The synchronization module is configured to execute a file synchronization process according to the mark.

[0117] It should be noted here that the various modules in this embodiment correspond one-to-one to the steps of the method in Example 1, and the specific implementation process is the same, which will not be repeated here.

[0118] Embodiment 3

[0119] This embodiment provides a cross-domain file server system, including a first file server and a second file server isolated from each other, and the first file server and the second file server can respectively implement unidirectional isolated transmission;

[0120] The first file server is configured to generate a first file list according to the files in the first file server; compare the first file list with the second file list received and sent by the second file server, mark the files in the first file server, determine the files that need to be synchronized with the second file server, and execute the file synchronization process;

[0121] The second file server is configured to generate a second file list based on the files in the second file server; compare the second file list with the first file list received and sent by the first file server, mark the files in the second file server, determine the files that need to be synchronized with the first file server, and execute the file synchronization process.

[0122] In this embodiment, the interaction process between the first file server and the second file server is the same as the specific implementation process of the method in Example 1. In Example 1, the process of synchronizing files from the first file server to the second file server is described, and the process of synchronizing from the second file server to the first file server is similar. When the two are executed synchronously, bidirectional synchronization of files between the cross-domain file server system including the first file server and the second file server is realized, so it will not be repeated here.

[0123] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A bidirectional synchronization method for cross-domain file servers based on file lists, characterized in that: include: Generate a first file list and a second file list according to the files in the first file server and the second file server respectively; Compare the first file list with the second file list, mark the files in the first file server and the second file server, and determine the files that need to be synchronized to the peer end; The file synchronization process is executed according to the mark.

2. A method for bidirectional synchronization of cross-domain file servers based on a file list as claimed in claim 1, characterized in that: The file list includes the file path, file name, file size, and the last update time of the file.

3. A method for bidirectional synchronization of cross-domain file servers based on file lists as claimed in claim 1, characterized in that: Comparing the first file list with the second file list, marking the files in the first file server and the second file server, and determining the files that need to be synchronized to the peer end, including: The first file server receives the second file list sent by the second file server, compares the received second file list with the generated first file list, marks the files in the first file server as the first mark, marks the same files as those in the second file server as the second mark, and marks the files that conflict with those in the second file server according to the file conflict policy; and / or, The second file server receives the first file list sent by the first file server, compares the received first file list with the generated second file list, marks the files in the second file server as the first mark, marks the files that are the same as those in the first file server as the second mark, and marks the files that conflict with those in the first file server according to the file conflict strategy.

4. A method for bidirectional synchronization of cross-domain file servers based on file lists as claimed in claim 3, characterized in that: When the file conflict strategy is a later time priority strategy, the file with an earlier time in the conflicting files is marked as the second mark; Alternatively, when the file conflict policy of one end of the first file server and the second file server is the local priority policy and the file conflict policy of the other end is the opposite side priority policy, the conflict file at the opposite side priority policy end is marked as the second mark.

5. A method for bidirectional synchronization of cross-domain file servers based on file lists as claimed in claim 1, characterized in that: The file synchronization process is executed according to the mark, including: The first file server synchronization process specifically includes: Compare the files in the first file server with the first file list, mark the added and / or changed files as a third mark, mark the reduced files as a fourth mark, mark the received file with the fifth mark sent by the second file server as the first mark and update it to the first file list; Synchronize the file marked with the third mark to the second file server, mark it with the sixth mark, and mark it with the second mark after receiving a message feedback from the second file server; Sending a deletion instruction for the corresponding file to the second file server according to the fourth mark, and marking it as the seventh mark after receiving a message feedback from the second file server; and / or, The second file server synchronization process specifically includes: Compare the files in the second file server with the second file list, mark the added and / or changed files as a third mark, mark the reduced files as a fourth mark, mark the received file with the fifth mark sent by the first file server as the first mark and update it to the second file list; Synchronize the file marked with the third mark to the first file server, mark it with the sixth mark, and mark it with the second mark after receiving a message feedback from the first file server; A deletion instruction for the corresponding file is sent to the first file server according to the fourth mark, and after receiving a message feedback from the first file server, it is marked as the seventh mark.

6. A method for bidirectional synchronization of cross-domain file servers based on file lists as claimed in claim 5, characterized in that: The first file server synchronization process also includes: receiving a file synchronized by the second file server, and marking the received file as a fifth mark; receiving a deletion instruction sent by the second file server, deleting the corresponding file in the first file server and marking it as a seventh mark; and / or, The second file server synchronization process also includes: receiving a file synchronized by the first file server, and marking the received file as a fifth mark; A deletion instruction sent by the first file server is received, and the corresponding file in the second file server is deleted and marked as a seventh mark.

7. A method for bidirectional synchronization of cross-domain file servers based on file lists as claimed in claim 5, characterized in that: It also includes deleting the corresponding marks of the synchronization files and deleting the files.

8. A method for bidirectional synchronization of cross-domain file servers based on file lists as claimed in claim 5, characterized in that: The method further includes determining whether the added and / or changed files are successfully written to the disk, and if successful, marking it as a third mark, otherwise marking it as an eighth mark.

9. A file list-based cross-domain file server bidirectional synchronization system, characterized in that: include: A file list generating module, configured to generate a first file list and a second file list according to files in the first file server and the second file server, respectively; A comparison module is configured to compare the first file list and the second file list, mark the files in the first file server and the second file server, and determine the files that need to be synchronized to the peer end; The synchronization module is configured to execute a file synchronization process according to the mark.

10. A cross-domain file server system, comprising a first file server and a second file server isolated from each other, wherein the first file server and the second file server can respectively implement unidirectional isolated transmission, characterized in that: The first file server is configured to generate a first file list according to the files in the first file server; compare the first file list with the second file list received and sent by the second file server, mark the files in the first file server, determine the files that need to be synchronized to the second file server, and execute the file synchronization process; The second file server is configured to generate a second file list according to the files in the second file server; The second file list is compared with the first file list received and sent by the first file server, the files in the second file server are marked, the files that need to be synchronized with the first file server are determined, and the file synchronization process is executed.

Images