WO2009137977A1 - 文件同步方法及装置 - Google Patents

文件同步方法及装置 Download PDF

Info

Publication number
WO2009137977A1
WO2009137977A1 PCT/CN2008/073693 CN2008073693W WO2009137977A1 WO 2009137977 A1 WO2009137977 A1 WO 2009137977A1 CN 2008073693 W CN2008073693 W CN 2008073693W WO 2009137977 A1 WO2009137977 A1 WO 2009137977A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
event
change
queue
synchronized
Prior art date
Application number
PCT/CN2008/073693
Other languages
English (en)
French (fr)
Inventor
张建勋
郑伟
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2009137977A1 publication Critical patent/WO2009137977A1/zh

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/178Techniques for file synchronisation in file systems

Definitions

  • the present invention relates to data synchronization technology, and in particular, to a file synchronization method and apparatus.
  • timing synchronization is usually used for file synchronization.
  • file synchronization There are two main methods:
  • Embodiments of the present invention provide a file synchronization method and apparatus to ensure real-time and reliability of file synchronization.
  • a file synchronization device provided by an embodiment of the present invention includes:
  • a recording unit configured to record a change event of the change when the monitoring unit monitors that a file in the file directory changes
  • a parsing unit configured to determine, according to the change event recorded by the recording unit, a file that needs to be synchronized
  • a synchronization unit configured to synchronize the file that needs to be synchronized to the destination machine.
  • the file synchronization method and device in the embodiment of the present invention monitors a file directory in real time, and records a change event when a file change is detected; and determines a need according to the change event. Synchronized files; synchronize the files that need to be synchronized to the destination machine. Therefore, the changed file can be immediately synchronized to the destination machine, ensuring the real-time and reliability of file synchronization.
  • FIG. 1 is a flowchart of an implementation of a file synchronization method according to an embodiment of the present invention
  • FIG. 2 is a flowchart of an implementation of recording a change event in an embodiment of the present invention
  • FIG. 3 is a flowchart of an implementation of analyzing a change event in an embodiment of the present invention.
  • FIG. 5 is a timing diagram of a file synchronization method according to an embodiment of the present invention.
  • Figure 6 is a block diagram showing the structure of a file synchronizing apparatus according to an embodiment of the present invention.
  • the changed file can be immediately synchronized to the destination machine.
  • the real-time monitoring mode is used, and when a file change is detected, the change event is recorded, and the change event is determined according to the change event. Synchronized files.
  • FIG. 1 it is an implementation process of the file synchronization method in the embodiment of the present invention, which mainly includes the following steps:
  • Step 101 Monitor the file directory, and record the change event of the change when the file in the file directory is monitored to change.
  • the interface of the operating system can be utilized, and the file change event notification mechanism is used.
  • the INOTIFY file change monitoring mechanism provided by the operating system can be used to monitor file changes in the file directory in real time;
  • the system interface ReadDirectoryChangesW can be used to monitor file changes in the file directory in real time. Due to the use of the operating system interface, the file change notification can be obtained at the first time after the file in the directory is modified, so that real-time synchronization of massive files can be realized.
  • other means or a customized means may also be used to monitor changes in files in the file directory.
  • a change event of a file change may be written to a specified queue, such as an event queue.
  • a specified queue such as an event queue.
  • the change event may also be changed. Write an unprocessed event file to ensure that the change event is not lost.
  • the existing unprocessed event file When an existing unprocessed event file is not processed, and an operating system notification event occurs, that is, the operating system monitors that the file in the file directory has changed, the existing unprocessed event file may be processed first, and the notification event is continuously written to the file. The event files are not processed, thus ensuring the order of file synchronization operations. This will be described in detail later.
  • Step 102 Determine, according to the change event, a file that needs to be synchronized.
  • the change event can be read from the event queue first, and the change event is parsed to determine the file that needs to be synchronized. If the event queue is empty, the unprocessed event file is read into the event queue, then the change event is read from the event queue, the change event is parsed, and the file to be synchronized is determined.
  • Step 103 Synchronize the files that need to be synchronized to the destination machine.
  • FTP File Transfer Protocol
  • socket socket
  • the embodiment records the change event of the file in the file directory, for example, using the operating system file change notification mechanism to ensure real-time synchronization, and the event file can be written to ensure synchronization. Reliability.
  • the change event may be recorded to the event queue. If the event queue is full or there is an unprocessed event file, the change event may be written into the unprocessed event file, and the unprocessed event file may be There are one or more to ensure that all change events are not lost. When there are multiple When processing event files, each unprocessed event file can be queued through the file queue to ensure that the files that have changed first can be preferentially synchronized.
  • FIG. 2 it is an implementation process for recording a change event in the embodiment of the present invention, which mainly includes the following steps:
  • Step 201 Obtain a file change event by using an operating system interface.
  • Step 202 Determine whether an unprocessed event file exists; if yes, execute step 203; otherwise, perform step 205.
  • Step 203 Determine whether there is an unprocessed event file that is not full; if yes, execute step 204; otherwise, perform step 207.
  • Step 204 Write a change event to an unprocessed event file that is not full, and the process ends.
  • Step 205 Determine whether the event queue is full; if yes, execute step 203; otherwise, execute step 206.
  • Step 206 Write a change event to the event queue, and the process ends.
  • Step 207 Create an unprocessed event file, and put the file name of the unprocessed event file into the file queue. This process ends.
  • the change event when the change event is processed, that is, when the change event is determined to determine the file that needs to be synchronized, the following process may be performed:
  • the event queue When the event queue is non-empty, the change event in the event queue is sequentially analyzed, and the event queue is determined.
  • the file that needs to be synchronized in the recorded change event when the event queue is empty, the change event in the unprocessed event file is loaded into the event queue, and the change event in the event queue is sequentially analyzed to determine the record in the unprocessed event file.
  • the file that needs to be synchronized in the change event after the change event in the unprocessed event file is loaded into the event queue, the unprocessed event file is deleted.
  • each unprocessed event file may be sequentially loaded into the event queue according to the order in the file queue, so as to ensure that the files that have changed first can be preferentially synchronized.
  • FIG. 3 it is an implementation process for analyzing a change event in the embodiment of the present invention, which mainly includes the following Steps:
  • Step 301 Determine whether the event queue is empty; if yes, execute step 302; otherwise, execute step 305.
  • Step 302 Determine whether the file queue is empty; if yes, execute step 307; otherwise, execute step 303.
  • Step 303 popping up the top element of the file queue as an unprocessed event file read into the event queue.
  • Step 304 Read the popped event file into the event queue.
  • Step 305 Read a change event from the head of the event queue.
  • Step 306 Analyze the change event, determine the file that needs to be synchronized, and the process ends.
  • Step 307 the change event is not read, and after waiting for the predetermined time, the reading process is resumed, and the process ends.
  • the real-time and reliability of synchronization can be ensured by the manner in which the change event is recorded as shown in FIG. 2 and the manner in which the change event is analyzed as shown in FIG. 3.
  • the status information of the directory at this time is recorded to the checkpoint information file, and is set to be a checkpoint after a certain time. Update the checkpoint information file when checking points and there are no pending unprocessed event files.
  • the directory status information recorded in the checkpoint information file determines the operation of each file in the directory, thereby determining whether the file needs to be synchronized.
  • FIG. 4 it is a flowchart of performing file directory scanning in the embodiment of the present invention, which mainly includes the following steps:
  • Step 401 Determine whether the checkpoint information file exists; if yes, execute step 402; otherwise, perform step 403;
  • Step 402 reading a checkpoint information file to obtain the latest checkpoint information; and then performing the step Step 404;
  • Step 403 create a new checkpoint information file, and initialize checkpoint information
  • Step 404 the root directory is pushed into the stack
  • Step 405 it is determined whether the stack is empty; if yes, step 406 is performed; otherwise, step 407 is performed;
  • Step 406 the scanning process ends, and the process ends.
  • Step 407 popping up the top element of the stack as the file directory to be scanned
  • Step 408 open a file directory to be scanned
  • Step 409 it is determined whether there is a file under the file directory; if yes, step 410 is performed; otherwise, step 405 is performed;
  • Step 410 Obtain a file in the file directory.
  • Step 411 it is determined whether the file is a directory; if yes, step 412 is performed; otherwise, step 413 is performed;
  • Step 412 pushing the directory onto the stack
  • Step 413 comparing the file information with the checkpoint information, determining whether file synchronization is required; if yes, executing step 414; otherwise, performing step 409;
  • step 414 file synchronization is performed, and the process ends.
  • the source machine can be scanned for the directory when the synchronization program is restarted, for example, full directory scanning, and the file change after the synchronization program is stopped can be guaranteed.
  • the directory scanning thread and the directory monitoring thread are simultaneously started, and the directory scanning thread ensures that the change information of the directory monitoring thread is synchronized or stopped, and the directory monitoring thread ensures that Real-time file change information is synchronized, so that the design can better ensure the real-time and reliability of file synchronization.
  • Step 501 Start a scan thread when starting a file synchronization task
  • Step 502 Start a monitoring thread.
  • Step 503 scanning a file directory to check whether a file has changed
  • Step 504 if there is a file change, the change file is synchronized
  • Step 505 monitoring the file directory in real time
  • Step 506 After monitoring the change event, recording the change event to the event queue;
  • Step 507 if the event queue is full or there is an unprocessed event file, the change event is written to the unprocessed event file;
  • Step 508 Read a change event in the event queue, and determine a file that needs to be synchronized
  • Step 509 if the event queue is empty, reading the change event in the unprocessed event file, and the file that needs to be synchronized;
  • unprocessed event file when reading an unprocessed event file, if there are multiple unprocessed event files, they can be read sequentially in the order of the file queue, and the change events in the unprocessed event file are loaded into the event queue. Then, the change event in the event queue is parsed in turn, and the files that need to be synchronized in the change event recorded in the unprocessed event file are determined. In addition, after the change event in the unprocessed event file is loaded into the event queue, the unprocessed event file needs to be deleted.
  • Step 510 Synchronize the changed file to the destination machine.
  • the unprocessed event file is generated when the event queue in the synchronization process is full, and the newly generated change event continues to be written to the unprocessed event file after the existing unprocessed event file is not processed.
  • Process event files After the unprocessed event file is loaded into the event queue, the unprocessed event file is deleted.
  • the existing unprocessed event file needs to be deleted.
  • the unprocessed event file is deleted.
  • the change event in the unprocessed event file can be completed by the scanning process after the next synchronization program is started.
  • the synchronization process can have multiple unprocessed event files. For convenience, you can set the number of change events recorded in each unprocessed event file to be the same, and equal to the size of the event queue in the synchronization process.
  • the size of the event queue can be specified when the synchronization program starts.
  • the event file can contain the following information: file name, file operation mode, file type, etc.
  • the specific format can be as shown in Table 1 below: Event file type identifier, event file maximum number of records
  • a single synchronization process has only one checkpoint information file, which is established when the synchronization process is started and cannot be found in the default path.
  • checkpoint information file The information and format contained in the checkpoint information file can be as shown in Table 2 below:
  • the checkpoint information can be updated periodically, and after the scheduled time arrives, if the directory scan has ended and there are no pending events, the checkpoint information is updated.
  • the history checkpoint information of the corresponding number can be retained according to the user's designation when starting the synchronization process.
  • the user starts the synchronization process he can specify which checkpoint information to use.
  • the number of checkpoint information to be reserved is ⁇
  • the position of the latest checkpoint information in the file is ⁇ ( ⁇ counts from 0)
  • the space occupied by the checkpoint information is ⁇ bytes, assuming that the checkpoint information file identifier occupies LA byte
  • the number of checkpoint information to be retained is LB bytes
  • the location of the latest checkpoint information in the file is occupied.
  • the location of the checkpoint information to be read LOCI is:
  • LOC 1 LA+LB+LC+P*M (Equation 1) Record the location of the next checkpoint information LOC2 as:
  • LOC2 LA+ LB + LC + ((P + 1) % N) * M (Equation 2) Obtain old checkpoint information from LOCI and scan the file. The new checkpoint information is set according to LOC2. If LOC2 already has checkpoint information, the old information will be overwritten.
  • the location of the checkpoint information is:
  • LOC3 LA+ LB + LC + (P + i) % N.
  • file synchronization can be ensured in real time, reliable, and efficient.
  • the embodiment of the present invention further provides a file synchronization device, as shown in FIG. 6, which is a structural block diagram of the file synchronization device, which mainly includes a monitoring unit 61, a recording unit 62, a parsing unit 63, and a synchronization unit.
  • a scanning unit 65 For further reliability of file synchronization, a scanning unit 65, a comparison unit 66, and a checkpoint time updating unit 67 may also be included. among them:
  • the monitoring unit 61 is configured to monitor the file directory; the recording unit 62 is configured to record the change event when the monitoring unit 61 detects that a file has changed; the parsing unit 63 is configured to determine that the synchronization is required according to the change event recorded by the recording unit 62.
  • File; synchronization unit 64 is used to synchronize the files that need to be synchronized to the destination machine.
  • the scanning unit 65 is configured to perform a directory scan on the source machine when the file synchronization task is started, and obtain a modification time of the file in the directory.
  • the comparison unit 65 is configured to compare the modification time of the file with the check point time of the last file recorded.
  • the notification synchronization unit 64 synchronizes the file to the destination machine; the checkpoint time update unit 66 is configured to synchronize the file to the destination at the comparison unit 65. After the machine, record the checkpoint time of this file synchronization.
  • the recording unit 62 may include the following subunits: a write queue subunit 621 for recording the change event to the event queue; and a write file subunit 622 for when the event queue is full or there is an unprocessed event file, Write the change event to the unprocessed event file.
  • the parsing unit 63 may include the following subunits: a queue parsing subunit 631, configured to sequentially parse the change event in the event queue when the event queue is non-empty, and determine the need for the change event recorded in the event queue.
  • the synchronized file the file parsing sub-unit 632 is configured to: when the event queue is empty, load the change event in the unprocessed event file into the event queue, and sequentially analyze the change event in the event queue to determine the Processing the file that needs to be synchronized in the change event recorded in the event file; the file deletion subunit 633 is configured to delete the unprocessed event file after the change event in the unprocessed event file is loaded into the event queue.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

文件同步方法及装置
本申请要求于 2008 年 5 月 13 日提交中国专利局、 申请号为 200810098124.2、 发明名称为"文件同步方法及装置,,的中国专利申请的优先 权, 其全部内容通过引用结合在本申请中。
技术领域
本发明涉及数据同步技术, 具体涉及一种文件同步方法及装置。
背景技术
在信息处理的多种应用环境中,数据同步都有着广泛的需求。 随着企业信 息化程度的提高, 考虑到数据的安全, 需要将一台主机上的文件同步到另外的 主机上进行备份; 在分布式系统中, 需要将基础数据文件同步到处于分布式系 统中的各个主机上。 满足同步需求的关键是要解决下列问题: 对文件同步的实 时性、 可靠性、 高效性, 以保证数据的安全可靠。
目前对文件同步通常釆用定时同步, 主要有以下两种方式:
1、 定时对源机需要同步的目录进行一次全扫描, 对每个扫描到的文件到 目的机验证,以确定该文件是否为新增或者做过修改,如果为新增或做过修改, 则将文件同步到目的机。
2、 定时对源机需要同步的目录进行一次全扫描, 对每个扫描后的文件先 进行同步操作, 然后将同步后的文件转移到本机备份目录。 以后每次扫描时, 都是处理新增文件。
上述这两种定时同步方式均不能同步删除文件;而且,不能做到实时同步, 可靠性较差。
发明内容
本发明实施例提供一种文件同步方法及装置,以保证文件同步的实时性和 可靠性。
本发明实施例提供的一种文件同步方法, 包括:
监控文件目录, 当监控到所述文件目录中的文件发生变化时, 记录该变化 的变化事件;
根据所述变化事件确定需要同步的文件;
将所述需要同步的文件同步到目的机。 本发明实施例提供的一种文件同步装置, 包括:
监控单元, 用于监控文件目录;
记录单元, 用于当所述监控单元监控到所述文件目录中的文件发生变化 时, 记录该变化的变化事件;
解析单元, 用于根据所述记录单元记录的变化事件确定需要同步的文件; 同步单元, 用于将所述需要同步的文件同步到目的机。
由以上本发明实施例提供的技术方案可以看出,本发明实施例的文件同步 方法及装置,实时监控文件目录, 当监控到有文件发生变化时,记录变化事件; 根据所述变化事件确定需要同步的文件; 将所述需要同步的文件同步到目的 机。 因此, 可以将发生变化的文件能立即同步到目的机上, 保证了文件同步的 实时性和可靠性。
附图说明
图 1是本发明实施例文件同步方法的一种实现流程图;
图 2是本发明实施例中记录变化事件的实现流程图;
图 3是本发明实施例中解析变化事件的实现流程图;
图 4是本发明实施例中进行文件目录扫描的流程图;
图 5是本发明实施例文件同步方法的一种时序图;
图 6是本发明实施例文件同步装置的结构框图。
具体实施方式
为了使本技术领域的人员更好地理解本发明实施例的方案,下面结合附图 和实施方式对本发明实施例作进一步的详细说明。
为了保证文件同步的实时性, 将发生变化的文件能立即同步到目的机上, 本发明实施例釆用实时监控方式,当监控到有文件发生变化时,记录变化事件, 并根据该变化事件确定需要同步的文件。
如图 1所示,是本发明实施例文件同步方法的一种实现流程, 主要包括以 下步骤:
步骤 101 , 监控文件目录, 当监控到该文件目录中的文件发生变化时, 记 录该变化的变化事件。
本实施例中, 可以利用操作系统的接口, 釆用文件变化事件通知机制, 实 时监控文件目录中文件的变化。 比如, 在 Linux操作系统下, 可以使用操作系 统提供的 INOTIFY文件变化监控机制, 实时监控文件目录中的文件变化; 在 Windows操作系统下, 可以利用系统接口 ReadDirectoryChangesW , 实时监控 文件目录中的文件变化。 由于操作系统接口的使用, 可以在目录中的文件修改 后的第一时间得到文件变化通知,从而可以实现海量文件的实时同步。 本发明 实例中, 也可以釆用其他手段或自定义的手段监控文件目录中文件的变化。
在本发明实施例中, 为了保证文件同步的可靠性, 可以将文件发生变化的 变化事件写到指定的队列, 比如事件队列, 在变化事件太多时, 比如事件队列 满后, 也可以将变化事件写入未处理事件文件, 以保证该变化事件不被丟失。
当既有未处理事件文件未处理,也有操作系统通知事件发生时, 即操作系 统监控到文件目录中的文件发生了变化, 可以先处理已存在的未处理事件文 件,将通知事件继续写入该未处理事件文件,从而保证文件同步操作的顺序进 行。 对此在后面将进行详细描述。
步骤 102, 根据该变化事件确定需要同步的文件。
相应地,可以首先从该事件队列中读取变化事件,对该变化事件进行解析, 确定需要同步的文件。如果该事件队列为空, 则将未处理事件文件读入该事件 队列, 然后, 从该事件队列中读取变化事件, 对该变化事件进行解析, 确定需 要同步的文件。
步骤 103 , 将该需要同步的文件同步到目的机。
进行文件同步的手段可以有多种, 例如 FTP ( File Transfer Protocol , 文件 传输协议)传输方式或者利用 socket (套接字) 方式, 实现同步文件的传输。
可见, 本发明实施例通过监控文件目录,记录该文件目录中的文件发生变 化的变化事件, 比如釆用操作系统文件变化通知机制, 可以保证同步的实时进 行, 通过写事件文件方式, 可以保证同步的可靠性。
下面对本发明实施例中记录变化事件及解析变化事件的流程进行详细说 明。
在本发明实施例中, 可以将该变化事件记录到事件队列,如果该事件队列 已满或有未处理事件文件, 则可以将该变化事件写入该未处理事件文件, 该未 处理事件文件可以有一个或多个, 以保证所有变化事件不会丟失。 当有多个未 处理事件文件时, 可以通过文件队列对各未处理事件文件进行排队, 以保证先 发生变化的文件能够得到优先同步处理。
如图 2所示,是本发明实施例中记录变化事件的实现流程, 主要包括以下 步骤:
步骤 201 , 利用操作系统接口获得文件变化事件。
比如, 在 Linux操作系统下, 使用操作系统提供的 INOTIFY文件变化监 控机制, 获取文件变化事件; 在 Windows 操作系统下, 利用系统接口 ReadDirectoryChangesW , 获取文件变化事件。
步骤 202 , 判断是否有未处理事件文件存在; 如果是, 则执行步骤 203; 否则, 执行步骤 205。
步骤 203 ,判断是否有未写满的未处理事件文件;如果是,则执行步骤 204; 否则, 执行步骤 207。
步骤 204, 将变化事件写入未写满的未处理事件文件, 本流程结束。
步骤 205 , 判断事件队列是否已满; 如果是, 则执行步骤 203 ; 否则, 执 行步骤 206。
步骤 206, 将变化事件写入事件队列, 本流程结束。
步骤 207 , 新建未处理事件文件, 并将该未处理事件文件的文件名放入文 件队列。 本流程结束。
相应地, 在处理变化事件时, 即解析变化事件确定需要同步的文件时, 可 以按照以下过程来进行: 当事件队列为非空时,依次解析该事件队列中的变化 事件,确定该事件队列中记录的变化事件中需要同步的文件; 当事件队列为空 后,将未处理事件文件中的变化事件加载到事件队列, 并依次解析该事件队列 中的变化事件, 确定该未处理事件文件中记录的变化事件中需要同步的文件; 在该未处理事件文件中的变化事件加载到该事件队列后,删除该未处理事件文 件。
需要说明的是,当有多个未处理事件文件时,可以根据文件队列中的顺序, 依次加载各未处理事件文件到该事件队列,以保证先发生变化的文件能够得到 优先同步处理。
如图 3所示,是本发明实施例中解析变化事件的实现流程, 主要包括以下 步骤:
步骤 301 , 判断事件队列是否为空; 如果是, 则执行步骤 302; 否则, 执 行步骤 305。
步骤 302 , 判断文件队列是否为空; 如果是, 则执行步骤 307 ; 否则, 执 行步骤 303。
步骤 303 ,弹出文件队列顶部元素,作为读入事件队列的未处理事件文件。 步骤 304 , 将弹出的事件文件读入事件队列。
步骤 305 , 从事件队列的队首读取一个变化事件。
步骤 306 , 解析变化事件, 确定需要同步的文件, 本流程结束。
步骤 307 , 未读取到变化事件, 等待预定时间后, 重新进行读取过程, 本 流程结束。
利用图 2所示记录变化事件的方式、 以及图 3所示解析变化事件的方式, 可以保证同步的实时性及可靠性。
为了进一步提高同步的高效性,还可以在启动文件同步任务时对源机进行 目录扫描, 比如全目录扫描, 获取该目录中文件的修改时间; 如果该文件的修 改时间比记录的上次文件同步的检查时间新, 则将该文件同步到目的机; 将该 文件同步到目的机后, 记录本次文件同步的检查点时间。
此外,还可以在第一次对文件目录扫描完,并且没有待处理的变化事件时, 记录此时目录的状态信息到检查点信息文件,并设定此后隔一定时间为一个检 查点, 当到达检查点、 并且没有待处理的未处理事件文件时, 更新检查点信息 文件。 下次扫描时, 4艮据检查点信息文件中记录的目录状态信息决定该目录下 的各个文件的操作,从而决定该文件是否需要同步。检查点信息文件的使用可 以加快后续扫描文件目录的速度, 减少网络交互,从而保证文件目录扫描的高 效运行。
如图 4所示,是本发明实施例中进行文件目录扫描的流程图, 主要包括以 下步骤:
步骤 401 , 判断检查点信息文件是否存在; 如果是, 则执行步骤 402; 否 则, 执行步骤 403 ;
步骤 402 , 读取检查点信息文件, 以获取最近的检查点信息; 然后执行步 骤 404;
步骤 403 , 新建检查点信息文件, 并初始化检查点信息;
步骤 404, 根目录进栈;
步骤 405 , 判断栈是否为空; 如果是, 则执行步骤 406; 否则, 执行步骤 407;
步骤 406, 结束扫描过程, 本流程结束。
步骤 407 , 弹出栈顶元素, 作为当前待扫描的文件目录;
步骤 408, 打开待扫描文件目录;
步骤 409 , 判断该文件目录下是否有文件; 如果是, 则执行步骤 410; 否 则, 执行步骤 405;
步骤 410, 获取该文件目录下的一个文件;
步骤 411 , 判断该文件是否为目录; 如果是, 则执行步骤 412; 否则, 执 行步骤 413;
步骤 412; 将该目录进栈;
步骤 413 , 将文件信息与检查点信息进行比较, 决定是否需要进行文件同 步; 如果是, 则执行步骤 414; 否则, 执行步骤 409;
步骤 414, 进行文件同步, 本流程结束。
利用该扫描流程, 可以进一步保证文件同步的可靠性。
在使用操作系统接口监控文件目录时,如果用于执行文件同步任务的同步 程序宕掉(比如程序异常发生的运行中止或程序重启动时)或是被人为停止掉, 那么之后产生的文件变化事件就捕捉不到,造成变化事件的丟失。 为解决这一 问题, 进一步保证同步的可靠性, 可以在重新启动同步程序时, 对源机进行目 录扫描, 比如全目录扫描, 可以保证得到同步程序停止后的文件变化。
也就是说, 本发明实施例中, 可以在启动文件同步任务时, 同时启动目录 扫描线程和目录监控线程,目录扫描线程保证目录监控线程宕掉或停止后的变 化信息得到同步, 目录监控线程保证实时的文件变化信息得到同步, 这样设计 可以更好地保证文件同步的实时性和可靠性。
如图 5所示,是本发明实施例文件同步方法的一种时序图,包括以下步骤: 步骤 501 , 在启动文件同步任务时启动扫描线程; 步骤 502 , 启动监控线程;
步骤 503 , 扫描文件目录, 以检查是否有文件发生变化;
步骤 504 , 如果有文件发生变化, 则同步变化文件;
步骤 505 , 实时监控文件目录;
步骤 506 , 监控到变化事件后, 将该变化事件记录到事件队列;
步骤 507 , 如果事件队列已满或有未处理事件文件, 则将变化事件写入该 未处理事件文件;
步骤 508 , 读取事件队列中的变化事件, 确定需要同步的文件;
步骤 509 , 如果事件队列空, 则读取未处理事件文件中的变化事件, 需要 同步的文件;
当然,如前面该,在读取未处理事件文件时,如果有多个未处理事件文件, 可以依照文件队列中的顺序依次读取,而且将未处理事件文件中的变化事件加 载到事件队列, 然后依次解析该事件队列中的变化事件, 确定该未处理事件文 件中记录的变化事件中需要同步的文件。 另外,在该未处理事件文件中的变化 事件加载到该事件队列后, 还需要删除该未处理事件文件。
步骤 510 , 将发生变化的文件同步到目的机。
需要说明的是, 在本发明实施例中, 该未处理事件文件在同步进程中的事 件队列满时产生, 新产生的变化事件在已有未处理事件文件没有处理完时, 继 续写入该未处理事件文件。在该未处理事件文件加载到事件队列后,删除该未 处理事件文件。 同步进程刚启动时, 需要删除已有的未处理事件文件, 同步进 程正常退出时删除未处理事件文件,该未处理事件文件中的变化事件可以由下 一次同步程序启动后的扫描进程来完成。
同步进程可以有多个未处理事件文件, 为了方便处理, 可以设定每个未处 理事件文件中记录的变化事件条数相同, 且等于同步进程中事件队列的大小。 事件队列的大小可以在同步程序启动时指定。
该事件文件中可以包含以下信息:文件名、文件的操作方式、文件类型等, 具体格式可以如下表 1所示: 事件文件类型标识, 事件文件最大记录数
Figure imgf000009_0001
其他己录
表 1
在上面已经提到, 可以在第一次对文件目录扫描完, 并且没有待处理的变 化事件时, 记录此时目录的状态信息到检查点信息文件。 下次扫描时, 根据检 查点信息文件中记录的目录状态信息决定该目录下的各个文件的操作,从而决 定该文件是否需要同步。
需要说明的是, 单个同步进程只有一个检查点信息文件, 该检查点信息文 件在同步进程启动时, 在默认路径中不能找到时建立。
该检查点信息文件中包含的信息及格式可以如下表 2所示:
Figure imgf000009_0002
表 2
检查点信息可以定时进行更新,在定时时间到达后,如果目录扫描已经结 束, 并且没有待处理的事件时, 更新该检查点信息。
检查点信息文件中, 可以根据用户在启动同步进程时的指定,保留相应数 目的历史检查点信息。用户在启动同步进程时,可以指定使用哪个检查点信息。 设需保留的检查点信息个数为 Ν,最新的检查点信息在文件中的位置为 Ρ(Ρ从 0开始计数),检查点信息所占空间为 Μ字节,假设检查点信息文件标识占 LA 字节, 需保留检查点信息个数占 LB字节, 最新检查点信息在文件中的位置占
LC字节。
在同步进程启动时, 若没有指定使用哪个检查点信息, 则所要读取的检查 点信息的位置 LOCI为:
LOC 1 =LA+LB+LC+P*M (公式 1 ) 记录下一个检查点信息的位置 LOC2为:
LOC2 = LA+ LB + LC + ((P + 1) % N) * M (公式 2 ) 根据 LOCI获取老的检查点信息, 进行文件扫描。根据 LOC2设置新的检 查点信息, 如果 LOC2已经有检查点信息, 旧的信息将被覆盖。
设置新的检查点信息的同时, 需要修改最新检查点信息的位置为:
P = ( P + 1 ) % N。
若指定使用第 1个检查点, 则检查点信息的位置为:
LOC3 = LA+ LB + LC + (P + i) % N。
利用本发明实施例的文件同步方法, 可以保证文件同步的实时、可靠和高 效。
需要说明的是,本领域普通技术人员可以理解实现上述实施例方法中的全 部或部分步骤是可以通过程序来指令相关的硬件来完成,该的程序可以存储于 一计算机可读取存储介质中, 该的存储介质, 如: ROM/RAM、磁碟、 光盘等。
本发明实施例还提供了一种文件同步装置,如图 6所示,是该文件同步装 置的结构框图, 主要包括监控单元 61、 记录单元 62、 解析单元 63和同步单元
64, 为了进一步文件同步的可靠性, 还可以包括扫描单元 65、 比较单元 66和 检查点时间更新单元 67。 其中:
监控单元 61用于监控文件目录; 记录单元 62用于当监控单元 61监控到 有文件发生变化时, 记录该变化的变化事件; 解析单元 63用于根据记录单元 62记录的变化事件确定需要同步的文件; 同步单元 64用于将该需要同步的文 件同步到目的机。 扫描单元 65用于在启动文件同步任务时对源机进行目录扫 描, 获取该目录中文件的修改时间; 比较单元 65用于比较该文件的修改时间 与记录的上次文件同步的检查点时间,如果该文件的修改时间比记录的上次文 件同步的检查点时间新, 则通知同步单元 64将该文件同步到目的机; 检查点 时间更新单元 66用于在比较单元 65将该文件同步到目的机后 ,记录本次文件 同步的检查点时间。
其中, 记录单元 62可以包括以下子单元: 写队列子单元 621 , 用于将该 变化事件记录到事件队列; 写文件子单元 622, 用于在该事件队列已满或有未 处理事件文件时, 将该变化事件写入该未处理事件文件。 相应地, 解析单元 63可以包括以下子单元: 队列解析子单元 631 , 用于 当该事件队列为非空时,依次解析该事件队列中的变化事件,确定该事件队列 中记录的变化事件中需要同步的文件; 文件解析子单元 632 , 用于当该事件队 列为空后, 将该未处理事件文件中的变化事件加载到该事件队列, 并依次解析 该事件队列中的变化事件,确定该未处理事件文件中记录的变化事件中需要同 步的文件; 文件删除子单元 633 , 用于在该未处理事件文件中的变化事件加载 到该事件队列后, 删除该未处理事件文件。
利用本发明实施例的装置实现文件同步的具体过程与前面对本发明方法 中的描述类似, 在此不再赘述。
以上对本发明实施例进行了详细介绍,本文中应用了具体实施方式对本发 明进行了阐述, 以上实施例的说明只是用于帮助理解本发明的装置及方法; 同 时, 对于本领域的一般技术人员, 依据本发明的思想, 在具体实施方式及应用 范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。

Claims

权 利 要 求
1、 一种文件同步方法, 其特征在于, 包括:
监控文件目录, 当监控到所述文件目录中的文件发生变化时, 记录该变化 的变化事件;
根据所述变化事件确定需要同步的文件;
将所述需要同步的文件同步到目的机。
2、 根据权利要求 1所述的方法, 其特征在于, 所述方法还包括: 在启动文件同步任务时对源机进行目录扫描,获取所述目录中文件的修改 时间;
如果所述文件的修改时间比记录的上次文件同步的检查时间新,则将所述 文件同步到目的机;
将所述文件同步到目的机后, 记录本次文件同步的检查点时间。
3、 根据权利要求 1或 2所述的方法, 其特征在于, 所述记录变化事件包 括:
将所述变化事件记录到事件队列;
如果所述事件队列已满或有未处理事件文件则将所述变化事件写入所述 未处理事件文件。
4、 根据权利要求 3所述的方法, 其特征在于, 所述根据所述变化事件确 定需要同步的文件包括:
当所述事件队列为非空时,依次解析所述事件队列中的变化事件,确定所 述事件队列中记录的变化事件中需要同步的文件;
当所述事件队列为空后,将所述未处理事件文件中的变化事件加载到所述 事件队列, 并依次解析所述事件队列中的变化事件,确定所述未处理事件文件 中记录的变化事件中需要同步的文件;
在所述未处理事件文件中的变化事件加载到所述事件队列后,删除所述未 处理事件文件。
5、 根据权利要求 1所述的方法, 其特征在于, 所述将需要同步的文件同 步到目的机包括:
利用文件传输协议或者 socket方式将需要同步的文件同步到目的机。
6、 根据权利要求 1所述的方法, 其特征在于, 利用操作系统的文件变化 事件通知机制实时监控所述文件目录。
7、 一种文件同步装置, 其特征在于, 包括:
监控单元, 用于监控文件目录;
记录单元, 用于当所述监控单元监控到所述文件目录中的文件发生变化 时, 记录该变化的变化事件;
解析单元, 用于根据所述记录单元记录的变化事件确定需要同步的文件; 同步单元, 用于将所述需要同步的文件同步到目的机。
8、 根据权利要求 7所述的装置, 其特征在于, 还包括:
扫描单元, 用于在启动文件同步任务时对源机进行目录扫描, 获取所述目 录中文件的爹改时间;
比较单元,用于比较所述文件的修改时间与记录的上次文件同步的检查点 时间,如果所述文件的修改时间比记录的上次文件同步的检查点时间新, 则通 知所述同步单元将所述文件同步到目的机;
检查点时间更新单元, 用于在所述比较单元将所述文件同步到目的机后, 记录本次文件同步的检查点时间。
9、 根据权利要求 1或 2所述的装置, 其特征在于, 所述记录单元包括: 写队列子单元, 用于将所述变化事件记录到事件队列;
写文件子单元, 用于在所述事件队列已满或有未处理事件文件时,将所述 变化事件写入所述未处理事件文件。
10、 根据权利要求 9所述的装置, 其特征在于, 所述解析单元包括: 队列解析子单元, 用于当所述事件队列为非空时,依次解析所述事件队列 中的变化事件, 确定所述事件队列中记录的变化事件中需要同步的文件; 文件解析子单元, 用于当所述事件队列为空后, 将所述未处理事件文件中 的变化事件加载到所述事件队列, 并依次解析所述事件队列中的变化事件,确 定所述未处理事件文件中记录的变化事件中需要同步的文件;
文件删除子单元,用于在所述未处理事件文件中的变化事件加载到所述事 件队列后, 删除所述未处理事件文件。
PCT/CN2008/073693 2008-05-13 2008-12-24 文件同步方法及装置 WO2009137977A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200810098124.2 2008-05-13
CN200810098124A CN100592298C (zh) 2008-05-13 2008-05-13 文件同步方法及装置

Publications (1)

Publication Number Publication Date
WO2009137977A1 true WO2009137977A1 (zh) 2009-11-19

Family

ID=40014011

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/073693 WO2009137977A1 (zh) 2008-05-13 2008-12-24 文件同步方法及装置

Country Status (2)

Country Link
CN (1) CN100592298C (zh)
WO (1) WO2009137977A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103327124A (zh) * 2013-07-12 2013-09-25 北京金山云网络技术有限公司 一种文件同步的方法、装置、客户端、服务器端及设备
CN111526198A (zh) * 2020-04-24 2020-08-11 深圳融安网络科技有限公司 服务器的数据同步方法、装置及计算机可读存储介质
CN117009309A (zh) * 2023-05-31 2023-11-07 合芯科技(苏州)有限公司 一种基于rsync的文件实时同步方法及装置

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100592298C (zh) * 2008-05-13 2010-02-24 华为技术有限公司 文件同步方法及装置
CN102567341B (zh) * 2010-12-09 2016-02-17 腾讯科技(深圳)有限公司 一种实现软件内外目录同步的方法和系统
CN102739706A (zh) * 2011-04-07 2012-10-17 腾讯科技(深圳)有限公司 进行数据同步的方法及系统
CN102609532B (zh) * 2012-02-15 2014-07-23 大唐移动通信设备有限公司 文件目录的监控方法和装置
CN102915338A (zh) * 2012-09-18 2013-02-06 浪潮(北京)电子信息产业有限公司 一种分布式文件系统数据同步的方法及文件系统
CN103258018B (zh) * 2013-04-27 2016-08-10 北京金和软件股份有限公司 一种精确监控目录文件夹中文件变化的文件同步方法
CN103336925B (zh) * 2013-07-29 2016-10-05 腾讯科技(深圳)有限公司 一种扫描加速的方法和装置
CN104348859B (zh) * 2013-07-30 2019-05-07 深圳市腾讯计算机系统有限公司 文件同步方法、装置、服务器、终端及系统
CN103561102B (zh) * 2013-11-08 2017-03-22 北京奇虎科技有限公司 数据实时同步方法及系统
CN103747029A (zh) * 2013-12-10 2014-04-23 北京奇虎科技有限公司 一种文件传输方法、设备和系统
CN103902663A (zh) * 2014-03-10 2014-07-02 联想(北京)有限公司 文件同步方法和装置
CN104133739B (zh) * 2014-07-28 2017-09-05 珠海市君天电子科技有限公司 一种自动备份文件的方法及装置
CN104994177B (zh) * 2015-08-06 2019-01-25 上海爱数信息技术股份有限公司 网盘系统的同步方法、终端设备和网盘系统
CN106610996B (zh) * 2015-10-23 2022-03-11 北京奇虎科技有限公司 热词典切换方法和装置
CN105426386A (zh) * 2015-10-23 2016-03-23 小米科技有限责任公司 文件同步方法、装置和终端设备
CN106372526B (zh) * 2016-08-19 2019-08-02 上海爱数信息技术股份有限公司 一种监控文件变化和同步的方法及系统
CN106572280B (zh) * 2016-10-12 2019-09-06 曙光信息产业(北京)有限公司 扫描文件的方法及系统
CN109446170B (zh) * 2018-09-13 2024-01-19 北京米文动力科技有限公司 一种配置文件数据同步方法及设备
CN109783463A (zh) * 2018-12-13 2019-05-21 杭州数梦工场科技有限公司 文件同步方法、装置及计算机可读存储介质
CN111488317A (zh) * 2020-04-16 2020-08-04 北京雷石天地电子技术有限公司 一种基于文件变化内容的文件同步方法和装置
CN111488318A (zh) * 2020-04-16 2020-08-04 北京雷石天地电子技术有限公司 一种基于多级反馈队列的文件同步方法和装置
CN111651414A (zh) * 2020-04-17 2020-09-11 福建天泉教育科技有限公司 监控文档被打开的方法、存储介质
CN114185749A (zh) * 2021-12-15 2022-03-15 南京欧珀软件科技有限公司 监控方法与装置、电子设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000075781A1 (en) * 1999-06-07 2000-12-14 Symantec Corporation Work monitor with file synchronization
CN1368683A (zh) * 2001-02-02 2002-09-11 英业达股份有限公司 利用同步目录容错的方法
CN1480859A (zh) * 2002-09-03 2004-03-10 鸿富锦精密工业(深圳)有限公司 分布式文件同步系统及方法
CN101281543A (zh) * 2008-05-13 2008-10-08 华为技术有限公司 文件同步方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000075781A1 (en) * 1999-06-07 2000-12-14 Symantec Corporation Work monitor with file synchronization
CN1368683A (zh) * 2001-02-02 2002-09-11 英业达股份有限公司 利用同步目录容错的方法
CN1480859A (zh) * 2002-09-03 2004-03-10 鸿富锦精密工业(深圳)有限公司 分布式文件同步系统及方法
CN101281543A (zh) * 2008-05-13 2008-10-08 华为技术有限公司 文件同步方法及装置

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103327124A (zh) * 2013-07-12 2013-09-25 北京金山云网络技术有限公司 一种文件同步的方法、装置、客户端、服务器端及设备
CN103327124B (zh) * 2013-07-12 2016-08-10 北京金山云网络技术有限公司 一种文件同步的方法、装置、客户端、服务器端及设备
CN111526198A (zh) * 2020-04-24 2020-08-11 深圳融安网络科技有限公司 服务器的数据同步方法、装置及计算机可读存储介质
CN111526198B (zh) * 2020-04-24 2023-06-13 深圳融安网络科技有限公司 服务器的数据同步方法、装置及计算机可读存储介质
CN117009309A (zh) * 2023-05-31 2023-11-07 合芯科技(苏州)有限公司 一种基于rsync的文件实时同步方法及装置
CN117009309B (zh) * 2023-05-31 2024-05-07 合芯科技(苏州)有限公司 一种基于rsync的文件实时同步方法及装置

Also Published As

Publication number Publication date
CN101281543A (zh) 2008-10-08
CN100592298C (zh) 2010-02-24

Similar Documents

Publication Publication Date Title
WO2009137977A1 (zh) 文件同步方法及装置
US7908339B2 (en) Transaction based virtual file system optimized for high-latency network connections
US7581136B2 (en) Method and apparatus for data recovery
US8458127B1 (en) Application data synchronization
WO2018049983A1 (zh) 数据同步方法、系统、同步获取方法及装置
US11687488B2 (en) Directory deletion method and apparatus, and storage server
JP4686587B2 (ja) 映像記録再生装置およびファイル管理方法
JP4224126B1 (ja) データベース管理サーバ装置、データベース管理システム、データベース管理方法およびデータベース管理プログラム
US20040083473A1 (en) Self-contained application disk for automatically launching application software or starting devices and peripherals
US20060015545A1 (en) Backup and sychronization of local data in a network
JP5445463B2 (ja) 計算機システム、データ保存方法およびプログラム
US20180077219A1 (en) Using Cloud Storage As Temporary Cache For Backup
WO2015081470A1 (zh) 数据处理设备和数据处理的方法
JP4371321B2 (ja) Nfsサーバ、nfsサーバ制御プログラム、nfsサーバ制御方法
WO2017113694A1 (zh) 文件同步方法、装置及系统
CN112416889A (zh) 分布式存储系统
WO2018014711A1 (zh) 一种录像播放方法及装置
JPWO2010052999A1 (ja) メンテナンスシステム、メンテナンス方法、及びメンテナンス用プログラム
CN114116611A (zh) 一种文件扫描方法及相关装置
JP2009080705A (ja) 仮想計算機システム及び同システムにおける仮想計算機復元方法
US20050138310A1 (en) Backup system and method and program
JP6324794B2 (ja) クラウド・ストレージ・システム
US20210271563A1 (en) Methods and systems for performing data backups
CN112925848A (zh) 一种数据同步方法、装置、设备及可读存储介质
CN116610501B (zh) Nas数据还原方法、装置、设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08874249

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08874249

Country of ref document: EP

Kind code of ref document: A1