CN114185749A

CN114185749A - Monitoring method and device and electronic equipment

Info

Publication number: CN114185749A
Application number: CN202111537172.9A
Authority: CN
Inventors: 唐迪娅; 钟云; 芦志朋
Original assignee: Nanjing Opper Software Technology Co ltd
Current assignee: Nanjing Opper Software Technology Co ltd
Priority date: 2021-12-15
Filing date: 2021-12-15
Publication date: 2022-03-15
Also published as: WO2023109272A1

Abstract

The application discloses a monitoring method and device and electronic equipment, wherein the method comprises the following steps: starting a monitoring thread in a process, wherein the monitoring thread is used for monitoring file change, the monitoring thread maintains a monitoring queue and an event queue, the monitoring queue is used for storing a path of a file to be monitored, and the event queue is used for storing an event corresponding to the change of the file; when a target file in a file to be monitored is changed, adding a first event corresponding to the change of the target file into an event queue; the control process takes out the first event from the event queue to complete the monitoring of the change of the target file, so that the file change is monitored, the monitoring operation and the interface of the file change which is easy to operate are provided, and then a user and a developer can monitor the flexibility, the diversity and the accuracy of the file change by only calling a small number of interfaces.

Description

Monitoring method and device and electronic equipment

Technical Field

The application relates to the technical field of computers, in particular to a monitoring method and device and electronic equipment.

Background

A distributed file system is made up of a plurality of (different) electronic devices. The distributed file system can break the storage boundary between the electronic devices, so that files can be freely and safely shared (synchronous/shared/coordinated) among a plurality of (different) electronic devices without borrowing third-party application.

However, the user may perform corresponding operations on the electronic device in the distributed file system, thereby causing changes (changes/alterations, etc.) to the file in the electronic device. Therefore, how to monitor (sense/capture, etc.) changes to the document requires further research.

Disclosure of Invention

The application provides a monitoring method and device and electronic equipment, which are used for monitoring file changes in hopes of realizing the monitoring operation and interface for providing the file changes easy to operate, and further enabling users and developers to monitor the file changes flexibly, diversely and accurately by only calling a small number of interfaces.

In a first aspect, a monitoring method according to the present application includes:

starting a monitoring thread in a process, wherein the monitoring thread is used for monitoring file change, the monitoring thread maintains a monitoring queue and an event queue, the monitoring queue is used for storing a path of a file to be monitored, and the event queue is used for storing an event corresponding to the change of the file;

when a target file in the files to be monitored is changed, adding a first event corresponding to the change of the target file into the event queue;

and controlling the process to take the first event out of the event queue to complete monitoring of the change of the target file.

In a second aspect, the present application is a monitoring device, including:

the device comprises an opening unit, a monitoring unit and an event queue, wherein the opening unit is used for opening a monitoring thread in a process, the monitoring thread is used for monitoring file change, the monitoring thread maintains a monitoring queue and the event queue, the monitoring queue is used for storing a path of a file to be monitored, and the event queue is used for storing an event corresponding to the change of the file;

the adding unit is used for adding a first event corresponding to the change of the target file into the event queue when the target file in the file to be monitored is changed;

and the control unit is used for controlling the process to take out the first event from the event queue so as to complete monitoring of the change of the target file.

In a third aspect, the present application is an electronic device, which includes a processor, a memory, and a computer program or instructions stored in the memory, where the processor executes the computer program or instructions to implement the steps in the method designed in the first aspect.

A fourth aspect is a computer-readable storage medium of the present application, in which a computer program or instructions are stored, which when executed, implement the steps in the method designed in the first aspect described above.

A fifth aspect is a computer program product of the present application, comprising a computer program or instructions, wherein the computer program or instructions, when executed, implement the steps of the method as designed in the first aspect.

It can be seen that, in the embodiment of the application, the file to be monitored is configured, the process and the monitoring thread are started, the monitoring queue and the event queue are maintained, the path of the file to be monitored is stored, the event corresponding to the change of the file is stored, and the event is taken out from the event queue, so that the file change is monitored, the monitoring operation and the interface of the file change which are easy to operate are provided, and further, a user and a developer can monitor the file change flexibly, diversely and accurately by only calling a small number of interfaces.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below.

FIG. 1 is a schematic diagram of an architecture of a distributed file system according to an embodiment of the present application;

fig. 2 is a schematic architecture diagram of a software and hardware system of an electronic device according to an embodiment of the present application;

FIG. 3 is a schematic structural diagram of an internal file structure of an electronic device according to an embodiment of the present application;

FIG. 4 is a schematic flow chart diagram of a monitoring method according to an embodiment of the present application;

FIG. 5 is a schematic flow chart illustrating overall monitoring of a setup directory according to an embodiment of the present application;

FIG. 6 is a schematic flow chart illustrating a single directory monitor according to an embodiment of the present application;

FIG. 7 is a schematic flow chart illustrating a process for setting directory comprehensive cancellation monitoring according to an embodiment of the present application;

FIG. 8 is a schematic flow chart illustrating a single directory revocation monitor setup according to an embodiment of the present application;

FIG. 9 is a schematic flow chart illustrating profile monitoring according to an embodiment of the present application;

FIG. 10 is a schematic flow chart illustrating monitoring cancellation of a profile according to an embodiment of the present application;

fig. 11 is a schematic structural diagram illustrating a local device and a remote device connected through a cross-port channel according to an embodiment of the present application;

fig. 12 is a schematic flowchart of monitoring file changes in a local device according to an embodiment of the present application;

FIG. 13 is a schematic flowchart of monitoring file changes in a remote device according to an embodiment of the present application;

FIG. 14 is a schematic flow chart diagram illustrating yet another monitoring method according to an embodiment of the present application;

fig. 15 is a block diagram of functional units of a monitoring apparatus according to an embodiment of the present application;

fig. 16 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

In order to better understand the technical solutions of the present application for those skilled in the art, the technical solutions in the embodiments of the present application are described below with reference to the drawings in the embodiments of the present application. It should be apparent that the embodiments described are some, but not all embodiments of the present application. All other embodiments obtained by a person of ordinary skill in the art without making any creative effort with respect to the embodiments in the present application belong to the protection scope of the present application.

It should be understood that the terms "first", "second", and the like, referred to in the embodiments of the present application, are used for distinguishing different objects, and are not used for describing a particular order. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, software, product, or apparatus that comprises a list of steps or elements is not limited to those listed but may include other steps or elements not listed or inherent to such process, method, product, or apparatus.

Reference in the specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the specification. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.

The term "at least one" in the embodiments of the present application means one or more, and a plurality means two or more.

"and/or" in the embodiment of the present application describes an association relationship of associated objects, and indicates that three relationships may exist, for example, a and/or B, and may indicate the following three cases: a exists alone, A and B exist simultaneously, and B exists alone. A, B may be singular or plural. The character "/" may indicate that the former and latter associated objects are in an "or" relationship. In addition, the symbol "/" may also indicate a division number, i.e. perform a division operation.

In the embodiments of the present application, "at least one item(s) below" or the like refers to any combination of these items, including any combination of a single item(s) or a plurality of items(s). For example, at least one (one) of a, b, or c may represent seven cases as follows: a, b, c, a and b, a and c, b and c, a, b and c. Each of a, b, and c may be an element or a set including one or more elements.

It should be noted that "change" appearing in the embodiments of the present application may be expressed as the same concept as "update", "modification", "change", and the like.

The "sharing" appearing in the embodiment of the present application may be expressed as the same concept as "synchronizing", "sharing", "coordinating", and the like. Thus, the shared file may be expressed as a synchronization file, a shared file, a collaborative file, or the like.

The "monitoring" appearing in the embodiments of the present application may be expressed as the same concept as "sensing", "monitoring", "detecting", "monitoring", "capturing", and the like. Thus, monitoring file changes may be expressed as perceiving file changes, capturing file changes, and the like. The files that are allowed to be monitored may be expressed as files that are allowed to be perceived, files that are allowed to be captured, and the like. The files that need to be monitored may be expressed as files that need to be sensed, files that need to be captured, etc.

With the development of technology and society, the world tends to be intercommunicated with each other, which brings great convenience to our lives. For example, a distributed file system consisting of multiple (different) electronic devices may break the storage boundary between electronic devices, such that files may be freely and securely shared or synchronized between the multiple (different) electronic devices without borrowing third party applications. The following requirements can thus be extracted:

1) a user wishes to be able to access files (not locally) in multiple (different) electronic devices at any time.

2) Users want to be able to have control over the sharing or synchronization of files (as desired).

However, with the sharing or synchronization of files, how to ensure the consistency of the files (i.e. the files are the same) in a plurality of (different) electronic devices without errors becomes a very critical issue.

If the file consistency cannot be guaranteed, the modification/change of the file on the electronic device a (such as a local device) by the user cannot be captured on the electronic device B (such as a remote device), that is, the modification/change of the file cannot be seen on the electronic device B by the user. Even a series of security problems may be introduced, for example, when a user cancels file sharing or modifies file attributes to be private on the electronic device a, the electronic device B cannot capture the operation, so that the electronic device B can still see the file, thereby bringing about a security risk.

In addition, in the distributed file system, when a user shares a file in the electronic device a to the electronic device B, the modification of the file by the user on the electronic device B also needs to be synchronized to the electronic device B, so as to avoid losing the modified file.

In summary, the embodiments of the present application need to ensure consistency, security, privacy, and real-time performance during file sharing (synchronization/sharing/coordination) in a distributed file system. Wherein, the following mode can be adopted:

1) by means of back-up

By backing up and uploading files regularly, changes/updates/revisions/changes to the files are completed, management is easy, but the real-time performance is poor, efficiency is low, a plurality of unchanged files are uploaded repeatedly, and the like.

2) By means of document monitoring

Compared with the mode, the change range can be limited in the specific file by adopting the file monitoring mode, and the change of the file can be sensed in real time and the response can be timely realized. Specifically, the following modes may be present:

one is that, under the environment of the Windows operating system, the monitoring of the file change is realized based on the readdirectorischanges interface provided by the Windows operating system.

However, in the file monitoring mode based on the Windows operating system, the interface provided by the Windows operating system is limited to the Windows platform, i.e. the Windows operating system can only be used in the Windows platform, and cannot be migrated to the Android system at will.

One is to realize monitoring of file change based on the Inotify kernel characteristic provided by the Linux operating system in the environment of the Linux operating system, that is, to analyze and process the monitored event of file change through the Inotify kernel characteristic, and to extract key information.

However, the file monitoring method based on the Inotify kernel characteristic of Linux is mainly used for monitoring local modification on one hand, and on the other hand, file monitoring is performed by directly using Inotify, which involves creating an Inotify instance, adding a monitor, creating an Epoll instance, registering an Epoll event for a file descriptor of the Inotify instance, and other operations, so that the method for file monitoring by using Inotify is complex in use, and is not beneficial to users and developers.

To sum up, the embodiments of the present application provide a monitoring method, which configures (sets/determines) a file to be monitored, constructs (creates) a monitoring queue and an event queue, reads a path of the file to be changed (updated/modified/changed, etc.) in the monitoring queue, captures an event of the file to be changed in the event queue, and takes out the event and analyzes and processes the event, thereby implementing a perception of the file change, i.e., monitoring the file, and providing a file monitoring operation and an interface that are simple and easy to operate, so that a user and a developer can flexibly monitor the file by only calling several interfaces, thereby facilitating to ensure consistency, security, privacy and real-time performance when sharing the file (synchronization/sharing/coordination equivalent) in a distributed file system.

Meanwhile, compared with a file monitoring mode based on a Windows operating system, the file monitoring method and device based on the Android operating system are beneficial to avoiding the limitation of the Windows platform, and the function of sensing the file change on the Android system is achieved.

Compared with a file monitoring mode based on the Inotify kernel characteristic of Linux, the configuration (setting/determining) of the embodiment of the application allows the operation of the monitored file to be relatively simple, and the scenes of the change of the file can be sensed to be richer. For example, only the top-level directory needs to be set, and full monitoring of the directory can be automatically realized. In addition, for the file monitoring in the embodiment of the present application, the file in the local device may be monitored, and the file in the remote device may also be monitored, that is, the change of capturing (monitoring) the file across terminals (among multiple/different electronic devices) is realized.

The following specifically describes technical solutions, advantageous effects and related concepts related to the embodiments of the present application.

1. Electronic device

In the embodiment of the present application, the electronic device may be a handheld device, a vehicle-mounted device, a wearable device, an Augmented Reality (AR) device, a Virtual Reality (VR) device, a projection device, a projector, or other devices connected to a wireless modem, or may be various User Equipments (UEs), terminal devices (terminal devices), terminals, mobile phones (smart phones), smart screens, smart televisions, smart watches, laptops, smart stereos, cameras, game pads, microphones, Stations (STAs), Access Points (APs), Mobile Stations (MSs), Personal Digital Assistants (PDAs), Personal Computers (PCs), or relay devices.

For example, the electronic device may be a wearable device. Wherein, this wearable equipment also can be called intelligent wearable equipment, is the general name of the smart machine who uses wearable technique to carry out intelligent design, development to daily wearing, for example smart glasses, intelligent gloves, intelligent wrist-watch, all kinds of intelligent bracelet, intelligent ornament etc. of specifically signing the monitoring. The wearable device can be worn directly on the body, and can also be integrated into a portable device on the clothing or accessories of the user. The wearable device can carry a special hardware framework, and can also carry a special software framework for data interaction, cloud interaction and the like. The wearable smart device may be independent of other smart devices to implement full or partial functionality.

2. Distributed file system, local device and remote device

The technical scheme of the embodiment of the application can be applied to a distributed file system, and the safety, consistency and real-time performance of file sharing (synchronization) are ensured. Wherein the distributed file system may be composed of a plurality of (different) electronic devices. The distributed file system can break the storage boundary between the electronic devices, so that files can be freely and safely shared (synchronized/shared/coordinated and the like) among a plurality of (different) electronic devices without borrowing third-party applications.

In addition, in the distributed file system, the local device may be referred to as an electronic device currently operated by the user, and the remote device may be referred to as another device other than the local device. The user can locally trigger the file change in the local terminal device through operation, and can also remotely trigger the file change in the remote terminal device through operating the local terminal device. The local device and the remote device may be interconnected and intercommunicated wirelessly or by wire, and may share file changes (synchronization/sharing/cooperation and the like) through a special cross-port channel (e.g., Google remote procedure call (grpc), Transmission Control Protocol (TCP), etc.).

Illustratively, as shown in FIG. 1, the distributed file system 10 may include at least two electronic devices 110. Among them, the at least two electronic devices 110 may include an electronic device 110A, an electronic device 110B, an electronic device 110C, an electronic device 110D, an electronic device 110E, and an electronic device 110F. Meanwhile, each of the at least two electronic devices 110 may be communicatively connected to each other through a wireless network or wired data.

It should be noted that the wireless network may include a mobile cellular network (e.g., a fifth generation 5G mobile communication network), a Wireless Local Area Network (WLAN), a Wide Area Network (WAN), Bluetooth (Bluetooth), wireless fidelity (Wi-Fi), Zigbee (Zigbee), Near Field Communication (NFC), Ultra Wide Band (UWB), or the like.

The wired data may include an HDMI data line, a USB data line, and the like.

Each of the at least two electronic devices 110 may be devices under the same user account. For example, when a user logs in to a mobile phone, a desktop computer, a smart screen, a notebook computer, a relay device and a smart watch using the same user account, the at least two electronic devices 110 include the mobile phone, the desktop computer, the smart screen, the notebook computer, the relay device and the smart watch, and the mobile phone, the desktop computer, the smart screen, the notebook computer, the relay device and the smart watch can communicate with each other through a wireless network.

Each of the at least two electronic devices 110 may be connected to the same WLAN network through a relay device (e.g., a router). For example, when a user accesses a mobile phone, a desktop computer, a smart screen, a notebook computer and a smart watch to a Wi-Fi network provided by a relay device, the at least two electronic devices 110 include the mobile phone, the desktop computer, the smart screen, the notebook computer, the relay device and the smart watch, and the mobile phone, the desktop computer, the smart screen, the notebook computer, the relay device and the smart watch form a WLAN network, so that the devices in the WLAN network can communicate with each other through the relay device.

Each of the at least two electronic devices 110 may form a Peer-to-Peer (P2P) network through a wireless communication manner (e.g., bluetooth, Zigbee, NFC, UWB, etc.). For example, a user scans an NFC tag to form a P2P network with a mobile phone, a notebook computer, a smart watch, etc., and all devices in the P2P network may have previously communicated with each other.

When a user operates a certain electronic device of the at least two electronic devices 110, the electronic device may be referred to as a home device, and other electronic devices except the electronic device may be referred to as remote devices.

In addition, the distributed file system 10 may also include other numbers of electronic devices, which are not specifically limited herein.

3. Software and hardware system of electronic equipment

In the embodiment of the present application, a software system of an electronic device may adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture.

The software and hardware system of the electronic device may include a hardware layer, an operating system layer running on top of the hardware layer, an application layer running on top of the operating system layer, and the like.

The hardware layer may include hardware such as a CPU, a Memory Management Unit (MMU), and a memory (also referred to as a memory).

The memory, which may be used to store software programs and/or modules, may include a program storage area and a data storage area.

The storage program area may be used to store an operating system or a software program required for at least one function. The operating system may be any one or more computer operating systems that implement business processes through processes. For example, an Android operating system, an RTOS (real-time operating system) operating system, a UNIX operating system, a Linux operating system, a DOS operating system, a Windows operating system, a Mac operating system, and the like.

The storage data area may be used for storing data and the like required or generated by an operating system or at least one function.

The following takes an operating system of a layered architecture as an example to exemplarily describe a software and hardware system of an electronic device.

Fig. 2 is a schematic diagram of an architecture of a software and hardware system of an electronic device according to an embodiment of the present application. The memory 220 stores therein an operating system layer 230. The operating system layers include a kernel layer 2301, a system runtime layer 2302, an application framework layer 2303, and an application layer 2304. Wherein, the layers communicate with each other through a software interface, and the kernel layer 2301, the system runtime layer 2302 and the application framework layer 2303 belong to an operating system space. Processor 210 may execute computer programs or instructions stored on memory 220 to perform related operations.

Processor 210, which may be considered a complete System On Chip (SOC), may be used to run or load an operating system and may include one or more processing units. For example, the processor 210 may include at least one of a Central Processing Unit (CPU), an Application Processor (AP), a Micro Controller Unit (MCU), a Single Chip Microcomputer (SCM), a single chip microcomputer (GPU), an Image Signal Processor (ISP), a controller, a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), an application-specific integrated circuit (ASIC), a baseband processor, a neural Network Processor (NPU), and the like. The different processing units may be separate or integrated. The memory 220 may also be provided in the processor 210.

The processor 210 may also include one or more communication interfaces. The communication interface may include at least one of a Serial Peripheral Interface (SPI), an integrated circuit (I2C) interface, an integrated circuit built-in audio (I2S) interface, a Pulse Code Modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a Mobile Industry Processor Interface (MIPI), a general purpose input/output (GPIO) interface, a Subscriber Identity Module (SIM) interface, a Universal Serial Bus (USB) interface, and the like.

Memory 220, which may be used to store computer programs or instructions, may be used to store data, and may be used to store operating system layer 230. Among other things, processor 210 may call programs stored in memory 220 to run an operating system. The memory 220 may store or cache instructions that have just been used or recycled by the processor 210, and may also store or cache data, which may be synchronized or transferred to other processors for execution.

The memory 220 may include at least one of a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a portable read-only memory (CD-ROM), or the like.

The kernel layer 2301 may provide underlying drivers for various hardware of the electronic device, such as a display driver, an audio driver, a camera driver, a bluetooth driver, a Wi-Fi driver, a power management, an NFC driver, a UWB driver, and so on.

The system runtime library layer 2302 may be used to provide the main feature support for the operating system via some C/C + + libraries. For example, the SQLite library provides support for a database, the OpenGL/ES library provides support for 3D drawing, the Webkit library provides support for a browser kernel, and the like.

The system Runtime layer 2302 may also be configured to provide an Android Runtime library (Android Runtime), which mainly provides some core libraries and can allow a developer to write an application using a scripting language.

The application framework layer 2303 may be used to provide various Application Programming Interfaces (APIs) and programming frameworks that may be used to build applications in the application layer 2304, so that developers may create applications by using the APIs.

The application framework layer 2303 may include a window manager (window manager), content providers (content providers), view system (view system), phone manager (telephone manager), resource manager, notification manager (notification manager), message manager, activity manager (activity manager), package manager (package manager), and location manager (location manager), among others.

The application layer 2304 belongs to a user space, and at least one application (application, also simply referred to as "application") runs in the application layer 2304. The application programs may be native applications of the operating system itself, or third-party applications developed by third-party developers. For example, the application layer may include applications such as camera, gallery, calendar, phone, map, navigation, WLAN, bluetooth, music, video, and short messages.

4. Applications, folders, processes, threads, directories and files of applications

1) Applications of

An application may be referred to as an application (application). An application program refers to a program that is run on an operating system, can run on an application layer, interacts with a user, and has a visual user interface for completing a specific task/tasks or having a certain function.

For example, an application may run on the application layer 2304 shown in fig. 2.

2) File folder for application

An application may generate (have) a folder that may be used to store files (data) for the application. For any electronic device, its internal file structure may be as shown in fig. 3.

In fig. 3, an application 310 and an application 320 run on the application layer of the electronic device 300. Among them, the application 310 has its own private folder 3101 for holding files (private data) of the application 310, such as pictures, videos, music, and documents. Meanwhile, the application 310 has a right to access a file (public data) in the public folder 330.

Similarly, the application 320 has its own private folder 3201 for holding files (private data) of the application 320, such as pictures, videos, music, and documents. At the same time, the application 320 also has access to files (public data) in the public folder 330.

3) Process and thread

The process may be a program with certain independent functions, may be a process of a single task executed by the CPU, may be a minimum unit of CPU resource allocation in the execution process of the program, and has its own address space (memory space).

The thread may be a minimum unit of CPU scheduling, may be a minimum unit of program execution, may be an independent execution unit in a process, and may be a complete flow of program execution.

A process may consist of at least one thread and the threads may be different execution routes of code in the process. The processes are independent from each other, but the memory space (including code segments, data sets, heaps, and the like) and some process-level resources of the process are shared among all threads under the same process.

4) Directory, current directory, parent directory and subdirectories

In the embodiment of the present application, the directory may be a folder. Therefore, the directory may be a private folder corresponding to the application, may be a public folder accessible by the application, may be a file in an internal file structure of the electronic device, and is not limited in particular.

In addition, in the directory structure, there are a current directory, a parent directory, and subdirectories. Wherein, the parent directory of the current directory is the superior directory of the current directory, and the subdirectory of the current directory is the next directory of the current directory.

For example, for directory structure c \ windows \ system32\ a \ b, if the current directory is directory a, directory b is the subdirectory of directory a, directory system32 is the parent directory of directory a, and directory \ windows is also the parent directory of directory a.

5) Document

In the embodiment of the present application, a file may be a unit defined for the purpose of implementing a certain function or a partial function of a certain software, and may refer to a collection of data stored on an external storage medium, may be a collection of information stored on a computer or an electronic device by using a computer hard disk or a memory as a carrier, may be video, audio, text, a document, a picture, a program, music, data, and the like, and may be any data generated during the operation of the electronic device or an operating system.

In addition, files may or may not be in directories (folders), may or may not be stored on a hard disk or in memory, and may or may not be stored on a computer-readable storage medium.

5. File changes

The file change is understood to mean a change in a file attribute, or the like. For example, the content of the file changes, the rights of the file change, etc.

The file content changes, which may include file content deletion, file content modification, file content update, file content addition, file content creation, and the like. For example, deleting a document, modifying a document, creating a document, playing music, playing a video, viewing a picture, deleting a picture, etc.

The change of the file authority may include a change of an access authority of the file (e.g., a change of the file from a public file to a private file, a change of the file from a private file to a public file, a change of the file to be accessible only by an administrator or a developer, etc.), a change of a monitoring authority of the file (e.g., a change of the file from a non-monitoring state to a monitoring state, a change of the file from a monitoring state to a non-monitoring state, a change of the file from a monitored state to a non-monitoring state, etc.).

In addition, the file change may be triggered by a user operating the electronic device. For example, the user clicks an application in the electronic device, the user deletes a certain file in the electronic device, and so on.

Taking the electronic device as a mobile phone and the user operating the application in the mobile phone as an example, an exemplary explanation is made on the file change.

For example, a user turns on music software in a cell phone (home device) to play a song. At this time, when the music software broadcasts a song, the operating system of the mobile phone performs a corresponding change operation on the file in the folder of the application of the music software.

For another example, a mobile phone (home device) is connected to a bluetooth speaker (remote device) through bluetooth, and the user controls the mobile phone to make the bluetooth speaker play songs in the music software of the mobile phone. At this time, when the music software broadcasts the song, the operation of the user on the mobile phone can be captured by the operating system of the bluetooth speaker through the cross-end channel, so that the operating system of the bluetooth speaker can perform corresponding change operation on the file in the folder for the music broadcasting application of the bluetooth speaker.

6. Monitoring status identification

In the embodiment of the present application, the monitoring state identifier includes a monitoring state identifier of a file and a monitoring state identifier of a directory.

1) Monitoring state identification of file

In the embodiment of the present application, each file may have a monitoring status identifier, and the monitoring status identifier may be used to indicate a monitoring status of the file (monitoring authority of the file), or the monitoring status identifier may be used to indicate whether the file is allowed to be monitored.

The monitored state of the file may be one of monitorable, unmonitorable, and monitored. That is, the monitoring status identifier of the file may be used to indicate one of monitorable, unmonitorable, and monitored.

The monitorable of the file may be used to indicate that the file is allowed to be monitored, but has not yet been monitored. Therefore, the electronic device (operating system) can perform monitoring processing on the monitorable file.

The unmonitorable of the file may be used to indicate that the file is not allowed to be monitored. Therefore, the electronic device (operating system) cannot monitor the unmonitorable files

The monitored of the file may be used to indicate that the file is allowed to be monitored and has been monitored. Therefore, the electronic device (operating system) may not monitor the monitored file any more, or may cancel monitoring of the monitored file to change to a monitorable or unmonitorable state.

In some possible designs, the monitoring status of the file may be configured (set) or modified according to the instruction of the user, or may be configured (set) by default from the factory.

For example, in a factory default situation, the monitoring state of a file is configured by default to be monitorable, i.e. allowed to be monitored but not yet monitored.

For another example, in the case of configuring according to the instruction of the user, the user may configure the monitoring state of the file as monitorable, unmonitorable or monitored according to the own requirement. At this time, the electronic device (operating system) may generate a configuration instruction of the user and execute the configuration instruction to implement a corresponding configuration operation.

For another example, in the case of modifying according to the instruction of the user, the user may modify the monitoring state of the file from monitorable to unmonitorable according to the needs of the user. At this time, the electronic device (operating system) may generate a modification instruction of the user and execute the modification instruction to implement a corresponding modification operation.

In some possible designs, the monitored state of the file may be set by default to monitorable, and the non-monitorable may only be configurable by the user. That is, unless the monitored status of a user profile is unmonitorable, the monitored status of the profile is not unmonitorable.

When the monitored state of the user profile is monitorable, the profile is appended with a monitorable identifier.

When the monitored state of the user profile is not monitorable, the profile is appended with an unmonitorable identifier.

When the monitoring status of the user profile is monitorable, the profile is appended with a monitorable identification.

2) Monitoring status identification for a directory

In addition to the above-mentioned type, each directory may have a monitoring status flag, and the monitoring status flag may be used to indicate the monitoring status of the directory (monitoring authority of the directory), or the monitoring status flag may be used to indicate whether the directory (all files under the directory) is allowed to be monitored.

The monitored state of the directory may be one of monitorable, unmonitorable, and monitored. That is, the monitoring status identification of the directory may be used to indicate one of monitorable, unmonitorable, and monitored.

The monitorable of a directory may be used to indicate that all files under the directory are allowed to be monitored, but have not yet been monitored. Therefore, the electronic device (operating system) can perform monitoring processing on the monitorable directory.

The unmonitorable of the directory may be used to indicate that all files under the directory are not allowed to be monitored. Therefore, the electronic device (operating system) cannot monitor the unmonitorable directory

The monitored of the directory may be used to indicate that all files under the directory are allowed to be monitored and have been monitored. Therefore, the electronic device (operating system) may not monitor the monitored directory any more, or may cancel monitoring of the monitored directory to change to a monitorable or unmonitorable state.

It should be noted that, when a directory is configured in a certain monitoring state (for example, it can be monitored), all files in the directory will be automatically configured in the same monitoring state, and it is not necessary to configure the monitoring state for each file in the directory in turn, so that the configuration is automatically performed to improve the configuration efficiency.

In addition, the monitored state of the directory is not configured (set) or modified recursively with the directory.

For example, if the monitoring status of the current directory is monitorable, the monitoring status of the sub-directory of the current directory is monitorable, and the monitoring status of the parent directory of the current directory is monitorable, when the monitoring status of the current directory is modified to be unmonitorable, the monitoring status of the sub-directory and the monitoring status of the parent directory are not modified and remain unchanged.

In some possible designs, the monitoring status of the directory may be configured (set) or modified according to the instruction of the user, or may be configured (set) by default from the factory.

For example, in a factory default case, the monitoring state of the directory is configured by default to be monitorable, i.e., allowed to be monitored but not yet monitored.

For another example, in the case of configuring according to the instruction of the user, the user may configure the monitoring state of the directory as monitorable, unmonitorable or monitored according to the own requirement. At this time, the electronic device (operating system) may generate a configuration instruction of the user and execute the configuration instruction to implement a corresponding configuration operation.

For another example, in the case of modification according to the instruction of the user, the user may modify the monitoring state of the directory from monitorable to unmonitorable according to the needs of the user. At this time, the electronic device (operating system) may generate a modification instruction of the user and execute the modification instruction to implement a corresponding modification operation.

In some possible designs, the monitoring status of the directory may be set by default to monitorable, and the non-monitorable may only be configurable by the user. That is, unless the user configures the monitored status of a directory to be unmonitorable, the monitored status of the directory will not be unmonitorable.

When the monitoring status of the user-configured directory is monitorable, the directory is appended with a monitorable identifier.

When the monitoring status of the user-configured directory is not monitorable, the directory is appended with an unmonitorable identifier.

7. Monitoring threads

In the embodiment of the present application, in order to monitor the file change, a thread may be specially started as a monitoring thread in the embodiment of the present application, and the monitoring thread may be used to monitor the file change.

In some possible designs, the supervisory thread may maintain a supervisory queue and an event queue.

A monitoring queue, which may be used to deposit (store/place, etc.) the path of the file that needs to be monitored. The monitoring queues are stored in sequence according to the sequence of path storage. The files that need to be monitored will be described in detail below.

The event queue may be used to store (store/place, etc.) events corresponding to changes in the file. The event queues are stored in sequence according to the sequence of event storage.

It should be noted that, in the embodiment of the present application, an event may be identified and operated by a control, may be processed by process parsing, may be referred to as a file change event, and may be triggered by a user. Each control (process) has events that it can recognize.

For example, when a user clicks an application through a display screen of the electronic device, an event is generated by an operating system of the electronic device.

An exemplary description of a flow executed by the monitoring method according to the embodiment of the present application is provided below with reference to a monitoring thread.

Exemplarily, as shown in fig. 4, the specific process is as follows:

step 1: starting a monitor thread 420 in the user process 410

A supervisory thread 420 in user process 410 is started by controlling kernel 450.

User process 410 is a process that is the process by which the CPU performs the user's individual tasks. The user process 410 is composed of at least one thread, and there is a thread for monitoring file change, namely a monitoring thread 420.

Monitor thread 420 maintains a monitor queue 430 and an event queue 440.

Step 2: monitor thread 420 adds a monitor object to monitor queue 430

The monitor object is added to the monitor queue 430 by controlling the monitor thread 420, so that the monitor queue 430 stores the path of the monitor object, such as the path 4301, the path 4302, the path 4303, and the like. The path of the monitoring object may include a path of a directory and a path of a file.

The path of a directory is the path of all files under the directory, i.e. the path of all files under the directory sharing the directory.

In addition, the monitoring queue 430 stores the paths in sequence, for example, the path 4301 is stored in the monitoring queue 430 first, and the path 4303 is stored in the monitoring queue 430 last.

And step 3: core 450 obtains monitored objects from monitor queue 430

Kernel 450 is a kernel in an operating system.

The kernel 450 is controlled to obtain the monitored objects from the monitoring queue 430, that is, the kernel 450 sequentially reads the paths in the monitoring queue 430, so that the kernel 450 can determine which files in the monitored files are allowed to be monitored through the path reading, that is, the files needing to be monitored, thereby monitoring the files needing to be monitored.

And 4, step 4: kernel 450 monitors for changes to a file and adds events to event queue 440

When the kernel 450 monitors (senses/captures, etc.) that there is a change in a file in the file to be monitored, the event queue 440 stores an event (change event) corresponding to the change in the file by controlling the kernel 450 to add the event (change event) to the event queue 440.

In addition, the event queue 440 stores the events in sequence, for example, the event 4401 is stored in the event queue 440 first, and the event 4403 is stored in the event queue 440 last.

And 5: the user process 410 takes out the event, parses the event, and generates a notification message

By controlling the user process 410 to fetch an event from the event queue 440, parse the event, and generate (trigger) a notification message. Wherein, the notification message is used to notify an application layer at an upper layer to perform a corresponding file change operation to complete monitoring (sensing/capturing, etc.) of a change of a file.

8. Monitoring arrangement allowing for files, files or directories to be monitored

1) Allowing monitored files, monitorable files

In combination with the above "6, monitoring status flag", the file or directory has the monitoring status flag. Therefore, the file whose monitoring status is monitorable may be referred to as a file allowed to be monitored.

That is, the file that is allowed to be monitored may be composed of a file whose monitoring state is monitorable (a file whose monitoring state identification indicates monitorable).

Or, the files allowed to be monitored may be determined by the monitoring status identifier.

It should be noted that the file that can be monitored may be in a directory, may not be in a directory, may be only in a current directory, may be only in a subdirectory of the current directory, may be only in a parent directory of the current directory, may be simultaneously in the current directory and a subdirectory of the current directory, may be simultaneously in the current directory and a parent directory of the current directory, and may be simultaneously in the current directory, a parent directory of the current directory, and a subdirectory of the current directory, which is not limited in particular.

2) Files that need to be monitored

In embodiments of the present application, files that are allowed to be monitored may include files that need to be monitored and files that do not need to be monitored.

3) Monitoring of files or directories

It should be noted that, the embodiment of the present application may provide an interface for setting monitoring of a file or a directory of a file that is allowed to be monitored, that is, setting monitoring and canceling monitoring, so as to determine a file that needs to be monitored, which is beneficial to finely dividing the monitoring granularity.

(ii) Single directory monitoring arrangement

A single directory monitoring setting may be used to set (configure) only the files under the current directory, but not the subdirectories monitoring the current directory, among the files that are allowed to be monitored.

It can be seen that the files to be monitored, determined by means of "single directory monitoring settings", may be only under the current directory.

Alternatively, files only under the current directory can be newly added to the files to be monitored by means of "single directory monitoring setting".

② directory comprehensive monitoring and setting

The directory comprehensive monitoring setting may be used to set (configure) files that are allowed to be monitored, and not only the files under the current directory need to be monitored, but also the files under all sub-directories of the current directory need to be monitored.

It can be seen that the files to be monitored determined by the "directory full monitoring setting" mode can be under the current directory and all the sub-directories of the current directory.

Or, the files under the current directory and all the subdirectories of the current directory can be newly added to the files to be monitored by the way of the "directory full monitoring setting".

Single directory cancel monitoring setting

A single directory unmonitoring setting may be used to set (configure) files that are allowed to be monitored, only files under the current directory need be unmonitored, and there is no need to recurse to monitoring subdirectories of the current directory.

It can be seen that the files deleted from the files that need to be monitored by means of "single directory cancel monitoring setting" may be only under the current directory.

Alternatively, files only under the current directory can be deleted from the files that need to be monitored by means of "single directory unsupervised settings".

Directory comprehensive cancel monitoring setting

The directory comprehensive cancellation monitoring setting can be used for setting (configuring) that monitoring of files under the current directory needs to be cancelled, and monitoring of all sub-directories of the current directory needs to be recursively cancelled.

It can be seen that the files deleted from the files to be monitored by the "directory cancel monitoring setting all over" mode can be under the current directory and all the sub-directories of the current directory at the same time.

Or, the files under the current directory and all the subdirectories of the current directory can be deleted from the files to be monitored simultaneously by the way of 'directory cancel monitoring setting completely'.

Document monitoring setting

File monitoring settings may be used to set (configure) the need to monitor a single or multiple files in allowing for the monitored files.

It can be seen that the files to be monitored determined by the "file monitoring setting" may be single or multiple.

Or, a single file or a plurality of files can be newly added to the file to be monitored by means of the file monitoring setting.

Cancellation of document monitoring settings

Canceling file monitoring settings may be used to set (configure) that monitoring is to be canceled for a single or multiple files in allowing monitored files.

It can be seen that the files deleted from the determined files that need to be monitored by means of "canceling file monitoring settings" may be single or multiple.

Alternatively, a single file or a plurality of files can be deleted from the files to be monitored by canceling the file monitoring setting.

4) How to determine the files that need to be monitored

It should be noted that the files to be monitored may be determined from the files that are allowed to be monitored.

In some possible designs, the files that need to be monitored may be determined from the files that are allowed to be monitored according to operating instructions.

That is, the operation instruction is generated according to the user's own needs, and a file that needs to be monitored is determined from files that are allowed to be monitored according to the operation instruction.

The operation instruction may be used to request to execute one of the above-mentioned single directory monitoring setting, directory comprehensive monitoring setting, single directory cancel monitoring setting, directory comprehensive cancel monitoring setting, file monitoring setting, and cancel file monitoring setting.

During specific implementation, the kernel can add the path of the file to be monitored to the monitoring queue according to the operation instruction, so that the file to be monitored is determined by adding the path; alternatively, the first and second electrodes may be,

the kernel can add or delete a path to the path of the file to be monitored stored in the monitoring queue according to the operation instruction, so that the file to be monitored is determined by adding or deleting the path, or the file to be monitored is updated by adding or deleting the path.

The following description is given by way of example with a setting that the operation instruction is used to request to perform comprehensive monitoring of the directory.

Exemplarily, as shown in fig. 5, the following process is specifically executed:

step 1: request for monitoring of a directory

When a user needs to perform comprehensive monitoring setting on the directory, an operation instruction is obtained, and the operation instruction can be used for requesting that the comprehensive monitoring setting on the directory needs to be performed, namely requesting that the directory is monitored.

The operation instruction may contain (carry) the path of the directory. All files under the directory may share the path of the directory, that is, the path of all files under the directory may be the path of the directory.

Step 2: determining whether all parent directories of the directory are allowed to be monitored

Since the user needs to perform a directory full monitoring setup on the directory, it is necessary to recursively determine (view/determine) whether all directories of the directory are allowed to be monitored. In this embodiment, the determination may be performed according to the monitoring status identifier.

If there is a parent directory that is not allowed to be monitored in all the parent directories of the directory, i.e., "no", it indicates that the parent directory has configured a label that is not allowed to be monitored, and then step 6 is executed.

If all the parent directories of the directory allow the monitored parent directory, i.e. "yes", it indicates that all the parent directories have configured the monitorable tag, and then step 3 is executed.

And step 3: adding the path of the directory in the monitoring queue

By adding the path of the directory to the monitoring queue, the kernel can read the path of the directory in the monitoring queue, so that files under the directory (all files under the directory are automatically determined) can be determined as files to be monitored, or files under the directory (all files under the directory are automatically added) can be added to the files to be monitored, and therefore the files to be monitored can be monitored.

And 4, step 4: judging whether there is a subdirectory under the directory

Since the user needs to perform a directory full monitoring setup for the directory, it is also necessary to recursively determine (view/determine) whether there are subdirectories under the directory.

In addition, since the operating system can automatically set an identifier for the directory, where the identifier is used to indicate that the directory is a directory, the embodiment of the application determines whether there are any subdirectories under the directory according to the identifier.

If there is no sub-directory under the directory, i.e. "no", the procedure is ended.

If there is a subdirectory under the directory, i.e. "yes", step 5 is performed.

And 5: adding the path of the subdirectory in the monitoring queue

And (5) repeating the step 4 and the step 5 until no sub-directory which is not monitored exists under the directory, thereby realizing the comprehensive directory monitoring setting of the directory.

In addition, by adding the path of the subdirectory of the directory to the monitoring queue, the kernel can read the path of the subdirectory in the monitoring queue, so that files under the subdirectory (all files under the subdirectory are automatically determined) can be determined as files to be monitored, or files under the subdirectory (all files under the subdirectory are automatically added) can be added to the files to be monitored, and therefore the files to be monitored can be monitored.

Step 6: canceling an execution request

That is, the request to execute the operation instruction is canceled.

The following description is exemplary provided by taking an example in which the operation instruction is used to request execution of a single directory monitoring setting.

Exemplarily, as shown in fig. 6, the following process is specifically executed:

step 1: request for monitoring of a directory

When a user needs to perform single directory monitoring setting on a directory, an operation instruction is obtained, and the operation instruction can be used for requesting that the single directory monitoring setting needs to be performed on the directory, namely requesting that the directory is monitored.

Step 2: determining whether the directory is allowed to be monitored

If the directory is not allowed to be monitored, i.e. "no", this indicates that the directory has been configured with a non-monitorable tag, at which point step 4 is performed. In this embodiment, the determination may be performed according to the monitoring status identifier.

If the directory is allowed to be monitored, i.e. "yes", this indicates that the directory has been configured with a monitorable tag, at which point step 3 is performed.

And step 3: adding the path of the directory in the monitoring queue

And 4, step 4: canceling an execution request

That is, the request to execute the operation instruction is canceled.

The following description is given by way of example with a setting that the operation instruction is used to request the execution directory to completely cancel monitoring.

Exemplarily, as shown in fig. 7, the following process is specifically executed:

step 1: requesting revocation of monitoring of a directory

When a user needs to perform comprehensive cancellation of monitoring setting on a directory, an operation instruction is obtained, and the operation instruction can be used for requesting that monitoring setting needs to be performed on the directory comprehensively, namely requesting to cancel monitoring on the directory.

Step 2: deleting path of the directory in the monitoring queue

By deleting the path of the directory from the monitoring queue, the kernel does not need to monitor the files under the directory (all the files under the directory), thereby realizing canceling monitoring of the directory.

And step 3: judging whether there is a subdirectory under the directory

Since the user needs to perform a directory full revocation monitoring setting for the directory, it is necessary to recursively determine (view/determine) whether there are subdirectories under the directory.

If there is a subdirectory under the directory, i.e. "yes", step 4 is performed.

And 4, step 4: deleting path of the subdirectory in the monitoring queue

And repeating the step 3 and the step 4 until no monitored subdirectory exists under the directory, thereby realizing that the directory is subjected to comprehensive cancel monitoring setting.

In addition, the path of the subdirectory is deleted from the monitoring queue, so that the kernel does not need to monitor the files under the subdirectory (all the files under the subdirectory), and the monitoring of the subdirectory is cancelled.

The following description is made by taking an example where the operation instruction is used to request execution of a single directory revocation monitoring setting.

Exemplarily, as shown in fig. 8, the following process is specifically executed:

step 1: requesting revocation of monitoring of a directory

When a user needs to perform single directory cancel monitoring setting on a directory, an operation instruction is obtained, and the operation instruction can be used for requesting that the single directory cancel monitoring setting needs to be performed on the directory, namely requesting to cancel monitoring on the directory.

Step 2: deleting path of the directory in the monitoring queue

The following description is made by taking an example of a setting that the operation instruction is used for requesting execution of file monitoring.

Exemplarily, as shown in fig. 9, the following process is specifically executed:

step 1: requesting that a file be monitored

When a user needs to perform file monitoring setting on a file, an operation instruction is obtained, and the operation instruction can be used for requesting that the file monitoring setting needs to be performed on the file, namely requesting to monitor the file.

The operation instruction may contain (carry) a path of the file.

Step 2: determining whether the file is allowed to be monitored

If the file is not allowed to be monitored, i.e. "no", this indicates that the file has been configured with a non-monitorable tag, at which point step 4 is performed. In this embodiment, the determination may be performed according to the monitoring status identifier.

If the file is allowed to be monitored, i.e. "yes", this indicates that the file has been configured with a monitorable tag, at which point step 3 is performed.

And step 3: adding the path of the file in the monitoring queue

The path of the file is added to the monitoring queue, so that the kernel can read the path of the file in the monitoring queue, the file can be determined to be the file to be monitored, or the file can be added to the file to be monitored, and the file to be monitored is monitored.

And 4, step 4: canceling an execution request

That is, the request to execute the operation instruction is canceled.

The following description is given by way of example with a setting that the operation instruction is used to request execution of file cancellation monitoring.

Illustratively, as shown in fig. 10, the following process is specifically performed:

step 1: requesting cancellation of monitoring of files

When a user needs to cancel the monitoring setting of the file, an operation instruction is obtained, and the operation instruction can be used for requesting that the monitoring setting of the file needs to be cancelled, namely requesting that the file is cancelled.

The operation instruction may contain (carry) a path of the file.

Step 2: deleting path of the file in the monitoring queue

By deleting the path of the file from the monitoring queue, the kernel does not need to monitor the file any more, and therefore monitoring of the file is cancelled.

9. Monitoring (sensing/capturing) file changes in a local device or a remote device

In combination with the above, after the file or the directory is monitored, the user may locally trigger the file change in the local device through operation, or may remotely trigger the file change in the remote device through operation of the local device.

Therefore, the embodiment of the application can monitor not only the file change in the local device, but also the file change in the remote device. Meanwhile, the changed files need to be shared (synchronized/shared/coordinated) between the local device and the remote device, so that consistency, security, privacy and instantaneity during file sharing are ensured in the distributed file system.

The following description is given by taking the example of connecting the local device and the remote device via the cross-port channel.

Illustratively, as shown in fig. 11, the local device 1110 and the remote device 1120 are connected by a cross-end channel 1130, and share of file change (synchronization/sharing/coordination) is realized by the cross-end channel 1130. The cross-end channel 1130 may be a grpc, a TCP, any channel for implementing cross-end communication, any channel with a remote file monitoring capability, or the like.

The home device 1110 has an application 1111 and an application 1112 running on an application layer. Among them, the application 1111 has its own private folder 1113 for saving files (private data) of the application 1111 such as pictures, videos, music, and documents. Meanwhile, the application 1111 has a right to access a file (public data) in the public folder 1114.

The application 1112 has its own private folder 1115 for holding files (private data) of the application 1112, such as pictures, videos, music, and documents. At the same time, the application 1112 also has access to files (public data) in the public folder 1114.

Similarly, an application 1121 and an application 1122 run on the application layer of the remote device 1120. Among them, the application 1121 has its own private folder 1123 for holding files (private data) of the application 1121, such as pictures, videos, music, and documents. Meanwhile, the application 1121 has a right to access a file (public data) in the public folder 1124.

Similarly, the application 1122 has its own private folder 1125 for holding files (private data) of the application 1122 such as pictures, videos, music, and documents. At the same time, the application 1122 also has the right to access the files (public data) in the public folder 1124.

The following describes an exemplary embodiment of monitoring a file change in a home device.

Exemplarily, as shown in fig. 12, the specific process is as follows:

step 1: user operation

As can be known from fig. 4, the core of the local device determines which files in the monitored files are allowed to be monitored, that is, files that need to be monitored, by reading the path stored in the monitoring queue, so as to monitor the files that need to be monitored.

When a user operates the local device, the user operation may cause a file to be changed in a file to be monitored, and the kernel may monitor (sense/capture, etc.) that the file is changed.

Step 2: the kernel monitors the file change of the local terminal equipment and adds an event to an event queue of the monitoring thread

When the kernel monitors that the file to be monitored has a file change, the kernel adds an event (change event) corresponding to the file change to the event queue so that the event queue stores the event (change event).

And step 3: the process takes out the event, parses the event, and triggers a notification mechanism

The event is pulled from the event queue by the control process, parsed, and a (trigger) notification message is generated. Wherein, the notification message is used for notifying an upper application layer to execute a corresponding file change operation.

And 4, step 4: the application layer executes corresponding file change operation

After receiving the notification message from the lower layer, the application layer performs a corresponding file change operation, for example, a file change result is presented on a display screen of the local device, thereby completing monitoring of the file change.

And 5: synchronizing changed files to a remote device

The local terminal equipment can synchronize the changed files to the remote terminal equipment through the cross-terminal channel, so that the files on the remote terminal equipment are correspondingly changed, and the consistency, the safety and the real-time performance of the files are further ensured.

The following is an exemplary description of a change in monitoring files in a remote device.

Exemplarily, as shown in fig. 13, the specific process is as follows:

step 1: user operation

As can be known from fig. 4, the core of the remote device determines which files in the monitored files are allowed to be monitored by reading the path stored in the monitoring queue, that is, the files that need to be monitored, so as to monitor the files that need to be monitored.

When a user remotely performs related operations on a remote device by operating a local device, the user operations may cause a file change in a file of the remote device that needs to be monitored, such as remotely modifying a document in the remote device, and a kernel of the remote device may monitor (sense/capture, etc.) that the file change.

Step 2: the kernel of the remote device monitors that the file of the kernel changes and adds an event to an event queue of a monitoring thread

When the kernel of the remote device monitors that the file to be monitored has a change, the kernel is controlled to add an event (change event) corresponding to the change of the file into the event queue, so that the event queue stores the event (change event).

And step 3: the process of the remote device fetches the event, parses the event, and triggers a notification mechanism

The event is taken out of the event queue by the process controlling the remote device, parsed and a (trigger) notification message is generated. Wherein, the notification message is used for notifying an application layer of an upper layer of the remote device to execute a corresponding file change operation.

And 4, step 4: the application layer of the remote device executes corresponding file change operation

After receiving the notification message from the lower layer, the application layer of the remote device performs a corresponding file change operation, for example, a file change result is presented on a display screen of the remote device, thereby completing monitoring of the file change.

And 5: the remote device synchronizes the changed file to the local device

The remote device can synchronize the changed files to the local device through the cross-terminal channel, so that the files on the local device are correspondingly changed, and the consistency, the safety and the real-time performance of the files are further ensured.

10. Exemplary description of a monitoring method

In summary, in order to realize the perception of the file change, a monitoring method according to an embodiment of the present application is described below as an example.

As shown in fig. 14, fig. 14 is a flowchart of a monitoring method according to an embodiment of the present application, which may be applied to any electronic device, operating system, kernel, processor or chip in a local device, a remote device, or a distributed file system, and specifically includes the following steps:

and S1410, starting a monitoring thread in a process, wherein the monitoring thread is used for monitoring file change, the monitoring thread maintains a monitoring queue and an event queue, the monitoring queue is used for storing a path of a file to be monitored, and the event queue is used for storing an event corresponding to the change of the file.

S1420, when the target file in the file to be monitored is changed, adding a first event corresponding to the change of the target file into the event queue.

S1430, the process is controlled to take out the first event from the event queue to complete the monitoring of the change of the target file.

It should be noted that, for example, the "process", "file", "event", "monitoring thread", "monitoring queue", "event queue", "file change", and "file to be monitored" may be specifically described in the above description, and are not described herein again.

The target file may be a file that is triggered to be changed by a user operation, and may be explained with reference to the content in the "file change", which is not described in detail herein.

The first event may be understood as an event that the operating system generates specifically for processing the change of the target file. The first event and the target file have a corresponding/association/mapping relation.

It can be seen that, in the embodiment of the application, the files to be monitored are configured, the process and the monitoring thread are started, the monitoring queue and the event queue are maintained, the path of the files to be monitored is stored, the events corresponding to the changes of the files are stored, and the events are taken out from the event queue, so that the changes of the files are monitored, the monitoring operation and the monitoring interface of the changes of the files which are easy to operate are provided, and then a user and a developer can monitor the changes of the files flexibly, diversely and accurately by only calling a small number of interfaces.

In some possible designs, the controlling the process in S1430 to fetch the first event from the event queue to complete the monitoring of the change of the target file may include: and the control process takes the first event out of the event queue to generate a first message, and the first message is used for informing the application layer of executing the change of the target file so as to complete the monitoring of the change of the target file.

Therefore, by triggering the notification mechanism, that is, generating the first message, the upper application layer can execute the change operation on the target file, for example, the file change result is presented on the display screen of the local device or the remote device, thereby being beneficial to ensuring the intuitive viewing of the user and completing the monitoring of the change of the target file.

In some possible examples, the file that needs to be monitored is in the home device; or, the file to be monitored is in a remote device; or the file to be monitored is a file in a private directory corresponding to the application; alternatively, the files that need to be monitored are files under a common directory that the application can access.

It should be noted that, as can be seen from the above content "9, monitoring (sensing/capturing) the file change in the local device or the remote device", the embodiment of the present application may implement monitoring of the file change in the local device or the remote device.

Therefore, the files to be monitored may be in the local device or the remote device, and this is not particularly limited.

In addition, as can be seen from the above "application, folder, process, thread, directory, and file of the application", the application according to the embodiment of the present application may have its own private folder (private directory) and have a right to access a file (public data) in a public folder (public directory).

Therefore, the files to be monitored may be files in a private directory corresponding to the application, or files in a public directory accessible by the application, which is not particularly limited.

In some possible designs, the files that need to be monitored are determined from the files that are allowed to be monitored; allowing the files to be monitored is determined by a monitoring state identifier, the monitoring state identifier is used for indicating the monitoring state of the files or the directories, and the monitoring state is one of monitorable, unmonitorable and monitored.

It should be noted that, as can be seen from the above contents in "6, monitoring status flag" and "8, file permitted to be monitored, and monitoring setting of file, file or directory required to be monitored", the embodiment of the present application may determine the file permitted to be monitored by introducing the monitoring status flag, and further determine the file required to be monitored in the file permitted to be monitored.

Further, the files to be monitored are determined from the files allowed to be monitored, and the method can comprise the following steps: the files to be monitored are determined from the files allowed to be monitored according to an operation instruction, wherein the operation instruction is used for requesting to execute one of single directory monitoring setting, directory comprehensive monitoring setting, single directory monitoring canceling setting, directory comprehensive monitoring canceling setting, file monitoring setting and file monitoring canceling setting.

It should be noted that, in combination with the content in the above "8, the files allowed to be monitored, and the monitoring settings of the files, files or directories that need to be monitored", the embodiment of the present application may determine different files that need to be monitored according to the difference requested by the operation instruction, thereby being beneficial to providing monitoring diversity and meeting different requirements of users.

In some possible designs, after S1410, the following steps may be further included: and adding or deleting paths to paths of files needing to be monitored and stored in the monitoring queue.

It should be noted that, as can be seen from the above "8, the files allowed to be monitored, the monitoring settings of the files, files or directories that need to be monitored" and the contents in fig. 5 to fig. 10, the embodiment of the present application may determine or update the files that need to be monitored by adding or deleting a path to the monitoring queue, thereby providing monitoring diversity and meeting the user requirements.

Further, adding a new path to the paths of the files to be monitored stored in the monitoring queue may include the following steps: acquiring a first operation instruction, wherein the first operation instruction is used for requesting to monitor a first directory; determining whether all parent directories of the first directory are allowed to be monitored; if the parent directory which is not allowed to be monitored exists in all the parent directories of the first directory, canceling the request for executing the first request message; and if all the parent directories of the first directory are allowed to be monitored, executing the request of the first request message, and adding the path of the first directory to the monitoring queue to finish adding the files under the first directory to the files needing to be monitored.

It should be noted that, as can be seen from fig. 5, in the embodiment of the present application, whether to add the path of the first directory to the monitoring queue or not may be determined by determining whether all parent directories of the first directory allow to be monitored, and whether to add the file in the first directory to the file to be monitored or not may be determined, so that the file to be monitored is determined or updated, which is further beneficial to providing monitoring diversity and meeting user requirements.

Further, after the path of the first directory is added to the monitoring queue, the following steps may be further included: determining whether a subdirectory exists under the first directory; and if the first sub-directory exists in the first directory, adding the path of the first sub-directory to the monitoring queue to finish adding the files in the first sub-directory to the files needing to be monitored.

It should be noted that, as can be seen from fig. 5, in the embodiment of the present application, it may also be determined whether to add a path of the first subdirectory to the monitoring queue by judging whether there is a subdirectory under the first directory, and determine whether to add a file under the first directory to a file to be monitored, so as to determine or update the file to be monitored, which is favorable for providing monitoring diversity and meeting user requirements.

Further, deleting a path from paths of files to be monitored stored in the monitoring queue, which need to be monitored, may include the following steps: acquiring a second operation instruction, wherein the second operation instruction is used for requesting to cancel monitoring of the second directory; and deleting the path of the second directory from the monitoring queue according to the second operation instruction so as to finish deleting the files under the second directory from the files to be monitored.

It should be noted that, as can be seen from fig. 7, in the embodiment of the present application, a path of the second directory can be deleted from the monitoring queue according to the operation instruction, and a file under the second directory is deleted from a file to be monitored, so that the file to be monitored is determined or updated, thereby being beneficial to ensuring the monitoring diversity and reliability, and meeting the user requirements.

Further, after deleting the path of the second directory from the monitoring queue according to the second operation instruction, the method may further include the following steps: determining whether a subdirectory exists under the second directory; and if the second sub-directory exists in the second directory, deleting the path of the second sub-directory from the monitoring queue to finish deleting the files in the second sub-directory from the files needing to be monitored.

It should be noted that, as can be seen from fig. 7, in the embodiment of the present application, a path of the second directory can be deleted from the monitoring queue according to the operation instruction, and a file under the second subdirectory of the second directory is deleted from a file to be monitored, so that the file to be monitored is determined or updated, thereby being beneficial to ensuring the monitoring diversity and reliability, and meeting the user requirement.

In some possible designs, after S1430, the following steps may be further included: and carrying out cross-device synchronization on the changed target file.

It should be noted that, as can be seen from the content in fig. 12 and 13, in combination with "9, monitoring (sensing/capturing) file change in the local device or the remote device", the local device may synchronize the changed file to the remote device, or the remote device may synchronize the changed file to the local device, so as to implement cross-device synchronization, thereby being beneficial to ensuring the consistency, security and real-time performance of the file.

11. Illustration of a monitoring device

The above description has introduced the solution of the embodiment of the present application mainly from the perspective of the method-side implementation process. It is understood that, in order to implement the above functions, the electronic device may include a corresponding hardware structure and/or software module for performing each function. Those of skill in the art would appreciate that the various illustrative methods, functions, modules, elements, or steps described in connection with the embodiments provided herein may be implemented as hardware or in combination with computer software. Whether a method, function, module, unit or step is performed by hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the technical solution. A person skilled in the art may use different methods to implement the described methods, functions, modules, units or steps for each specific application, but such implementation should not be considered as beyond the scope of the present application.

The embodiment of the present application may perform the division of the functional units/modules according to the above method examples. For example, each functional unit/module may be divided for each function, or two or more functions may be integrated into one functional unit/module. The integrated functional units/modules may be implemented in a hardware manner or a software program manner. It should be noted that, in the embodiment of the present application, the division of the functional units/modules is schematic, and only one logical function division is used, and there may be another division manner in actual implementation.

In the case of an integrated unit, fig. 15 is a block diagram of functional units of a monitoring apparatus according to an embodiment of the present application. The monitoring apparatus 1500 includes: an opening unit 1510, an adding unit 1520, and a control unit 1530.

In some possible designs, the opening unit 1510, the adding unit 1520 and the control unit 1530 may be separate from each other, and may be integrated in the same unit.

For example, the opening unit 1510, the adding unit 1520, and the control unit 1530 may be integrated in the processing unit. The processing unit may be a processor or a controller, and may be, for example, a Central Processing Unit (CPU), a general purpose processor, a Digital Signal Processor (DSP), an application-specific integrated circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, a transistor logic device, a hardware component, or any combination thereof. Which may implement or perform the various illustrative logical blocks, modules, and circuits described in connection with the disclosure. A processing unit may also be a combination that performs computing functions, e.g., a combination of one or more microprocessors, a DSP and a microprocessor, etc.

In some possible designs, monitoring device 1500 may also include a storage unit for storing computer programs or instructions for execution by data monitoring device 1500. The storage unit may be a memory.

In some possible designs, the monitoring apparatus 1500 may be a chip/chip module/processor/electronic device/operating system.

In a specific implementation, the opening unit 1510, the adding unit 1520 and the control unit 1530 are configured to perform the steps described in the above method embodiments. The details will be described below.

The starting unit 1510 is configured to start a monitoring thread in a process, where the monitoring thread is configured to monitor a file change, the monitoring thread maintains a monitoring queue and an event queue, the monitoring queue is configured to store a path of a file to be monitored, and the event queue is configured to store an event corresponding to the file change;

an adding unit 1520, configured to add, when there is a change in a target file in a file that needs to be monitored, a first event corresponding to the change in the target file to an event queue;

the control unit 1530 is configured to control the process to fetch the first event from the event queue to complete monitoring of the change of the target file.

It should be noted that, for specific implementation of each operation performed by the monitoring apparatus 1500, reference may be made to the corresponding description of the foregoing method embodiment, and details are not described herein again.

In some possible designs, in terms of the control process fetching the first event from the event queue to complete the monitoring of the change to the target file, the control unit 1530 is configured to:

and the control process takes the first event out of the event queue to generate a first message, and the first message is used for informing the application layer of executing the change of the target file so as to complete the monitoring of the change of the target file.

In some possible designs, the files that need to be monitored are in the home device; or, the file to be monitored is in a remote device; or the file to be monitored is a file in a private directory corresponding to the application; alternatively, the files that need to be monitored are files under a common directory that the application can access.

In some possible designs, the files that need to be monitored are determined from files that allow for monitoring, including: the files to be monitored are determined from the files allowed to be monitored according to an operation instruction, wherein the operation instruction is used for requesting to execute one of single directory monitoring setting, directory comprehensive monitoring setting, single directory monitoring canceling setting, directory comprehensive monitoring canceling setting, file monitoring setting and file monitoring canceling setting.

In some possible designs, after the monitoring thread is started, the monitoring apparatus 1500 further includes:

and the setting unit is used for adding or deleting paths to the paths of the files to be monitored stored in the monitoring queue.

In some possible designs, in terms of adding a path to the paths of the files to be monitored stored in the monitoring queue, the setting unit is configured to:

acquiring a first operation instruction, wherein the first operation instruction is used for requesting to monitor a first directory;

determining whether all parent directories of the first directory are allowed to be monitored;

if the parent directory which is not allowed to be monitored exists in all the parent directories of the first directory, canceling the request for executing the first request message;

and if all the parent directories of the first directory are allowed to be monitored, executing the request of the first request message, and adding the path of the first directory to the monitoring queue to finish adding the files under the first directory to the files needing to be monitored.

In some possible designs, after adding the path of the first directory to the monitoring queue, the monitoring apparatus 1500 further includes:

a determining unit, configured to determine whether a subdirectory exists under the first directory; and if the first sub-directory exists in the first directory, adding the path of the first sub-directory to the monitoring queue to complete the addition of the files in the first sub-directory to the files needing to be monitored.

In some possible designs, in deleting a path from the paths of the files to be monitored stored in the monitoring queue, the setting unit is configured to:

acquiring a second operation instruction, wherein the second operation instruction is used for requesting to cancel monitoring of the second directory;

and deleting the path of the second directory from the monitoring queue according to the second operation instruction so as to finish deleting the files under the second directory from the files to be monitored.

In some possible designs, after deleting the path of the second directory from the monitoring queue according to the second operation instruction, the monitoring apparatus 1500 further includes:

a determining unit, configured to determine whether a sub-directory exists under the second directory; and if the second sub-directory exists in the second directory, deleting the path of the second sub-directory from the monitoring queue to finish deleting the files in the second sub-directory from the files needing to be monitored.

In some possible designs, after the control process fetches the first event from the event queue to complete the monitoring of the change of the target file, the monitoring apparatus 1500 further includes:

and a synchronization unit for performing cross-device synchronization on the changed target file.

12. Illustration of an electronic device

A schematic structural diagram of an electronic device according to an embodiment of the present application is described below, as shown in fig. 16. The electronic device 1600 includes a processor 1610, a memory 1620, and a communication bus for connecting the processor 1610 and the memory 1620.

The processor 1610 may be one or more central processing units CPU. In the case where the processor 1610 is a CPU, the CPU may be a single core CPU or a multi-core CPU. The memory 1620 includes, but is not limited to, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or a portable read-only memory (CD-ROM), and the memory 1620 is used to store computer programs or instructions.

The electronic device 1600 also includes a communication interface for receiving and transmitting data.

The processor 1610 in the electronic device 1600 is configured to execute the computer programs or instructions 1621 stored in the memory 1620 to implement the steps in the method as designed:

when a target file in a file to be monitored is changed, adding a first event corresponding to the change of the target file into an event queue;

and the control process takes the first event out of the event queue to complete the monitoring of the change of the target file.

It should be noted that, for specific implementation of each operation performed by the electronic device 1600, reference may be made to the corresponding description of the method embodiment shown above, and details are not described here again.

In some possible designs, in terms of the control process fetching a first event from the event queue to complete the monitoring of the change to the target file, the processor 1610 is configured to execute the computer program or instructions 1621 stored in the memory 1620 to implement the steps in the method as designed below:

In some possible designs, after the monitoring thread is turned on, processor 1610 is further configured to execute computer programs or instructions 1621 stored in memory 1620 to implement the steps in the method as designed:

and adding or deleting paths to paths of files needing to be monitored and stored in the monitoring queue.

In some possible designs, in adding a new path to the path of the file to be monitored stored in the monitoring queue, the processor 1610 is configured to execute the computer program or instructions 1621 stored in the memory 1620 to implement the steps in the method as designed below:

In some possible designs, after adding the path of the first directory to the monitoring queue, processor 1610 is further configured to execute computer program or instructions 1621 stored in memory 1620 to implement the steps in the method as designed:

determining whether a subdirectory exists under the first directory;

and if the first sub-directory exists in the first directory, adding the path of the first sub-directory to the monitoring queue to finish adding the files in the first sub-directory to the files needing to be monitored.

In some possible designs, in deleting paths from paths of files stored in the monitoring queue that need to be monitored, processor 1610 is configured to execute computer programs or instructions 1621 stored in memory 1620 to implement steps in a method designed as follows:

In some possible designs, after deleting the path of the second directory from the monitoring queue according to the second operation instruction, the processor 1610 is further configured to execute the computer program or the instructions 1621 stored in the memory 1620 to implement the steps in the method as designed below:

determining whether a subdirectory exists under the second directory;

and if the second sub-directory exists in the second directory, deleting the path of the second sub-directory from the monitoring queue to finish deleting the files in the second sub-directory from the files needing to be monitored.

In some possible designs, after the control process fetches the first event from the event queue to complete the monitoring of the change to the target file, the processor 1610 is further configured to execute the computer program or instructions 1621 stored in the memory 1620 to implement the steps in the method as designed below: and carrying out cross-device synchronization on the changed target file.

Embodiments of the present application also provide a computer-readable storage medium, which stores a computer program or instructions, and the computer program or instructions implement the steps of the method designed in the above embodiments when executed.

Embodiments of the present application further provide a computer program product, which includes a computer program or instructions, where the computer program or instructions are executed to implement the steps in the method designed in the above embodiments.

Illustratively, the computer program product may be a software installation package.

For simplicity of description, the above embodiments are described as a series of combinations of operations. Those skilled in the art should appreciate that the present application is not limited by the order of acts described, as some steps in the embodiments of the present application may occur in other orders or concurrently. In addition, those skilled in the art should also realize that the embodiments described in the specification all belong to the preferred embodiments, and that the referred actions, steps, modules, units, and the like are not necessarily required by the embodiments of the present application.

In the foregoing embodiments, the descriptions of the embodiments of the present application have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

Each device and product described in the above embodiments includes modules/units, which may be software modules/units, or hardware modules/units, or may be partly software modules/units and partly hardware modules/units. For example, for each device or product of an application or integrated chip, each module/unit included in the device or product may be implemented by hardware such as a circuit, or at least a part of the modules/units may be implemented by a software program, which runs on an integrated processor inside the chip, and the rest of the modules/units may be implemented by hardware such as a circuit; for each device and product corresponding to or integrating the chip module, each module/unit included in the device and product can be implemented by adopting hardware such as a circuit, different modules/units can be positioned in the same piece (such as a chip, a circuit module and the like) or different components of the chip module, at least part of/unit can be implemented by adopting a software program, and the software program runs in the chip module, and the rest of the modules/units of the integrated processor can be implemented by adopting hardware such as a circuit; for each device or product corresponding to or integrating the terminal, the modules/units included in the device or product may all be implemented by hardware such as circuits, different modules/units may be located in the same component (e.g., chip, circuit module, etc.) or different components in the terminal, or at least some of the modules/units may be implemented by software programs, the programs run on a processor integrated in the terminal, and the remaining sub-modules/units may be implemented by hardware such as circuits.

It should be clear to a person skilled in the art that the methods, steps or functions of related modules/units described in the embodiments of the present application can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented in software, it may be implemented in whole or in part in the form of a computer program product or in the form of computer program instructions executed by a processor. Wherein the computer program product comprises at least one computer program instruction, which may consist of corresponding software modules, which may be stored in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, a removable hard disk, a compact disc read only memory (CD-ROM), or any other form of storage medium known in the art. The computer program instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium. For example, the computer program instructions may be transmitted from one website site, computer, server, or data center to another website site, computer, server, or data center by wired or wireless means. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that includes one or more of the available media. The available media may be magnetic media (e.g., floppy disks, hard disks, tapes), optical media, or semiconductor media (e.g., SSDs), among others.

Each module/unit included in each apparatus or product described in the above embodiments may be a software module/unit, a hardware module/unit, or a part of the module/unit may be a software module/unit and another part may be a hardware module/unit. For example, for each device or product applied to or integrated on a chip, each module/unit included in the device or product may be implemented by using hardware such as a circuit; alternatively, a part of the modules/units included in the method may be implemented by using a software program running on a processor integrated inside a chip, and another part (if any) of the modules/units may be implemented by using hardware such as a circuit. The same applies to individual devices or products applied to or integrated in a chip module, or to individual devices or products applied to or integrated in a terminal.

The above-mentioned embodiments are intended to illustrate the objects, technical solutions and advantages of the embodiments of the present application in further detail, and it should be understood that the above-mentioned embodiments are only specific embodiments of the present application, and are not intended to limit the scope of the embodiments of the present application. Any modification, equivalent replacement, improvement and the like made on the basis of the technical solutions of the embodiments of the present application should be included in the protection scope of the embodiments of the present application.

Claims

1. A method of monitoring, comprising:

2. The method of claim 1, wherein the controlling the process to fetch the first event from the event queue to complete the monitoring of the change of the target file comprises:

and controlling the process to take the first event out of the event queue to generate a first message, wherein the first message is used for notifying an application layer to execute the change of the target file so as to complete the monitoring of the change of the target file.

3. The method of claim 1, wherein the file to be monitored is in a home device; alternatively, the first and second electrodes may be,

the file to be monitored is in a remote device; alternatively, the first and second electrodes may be,

the files to be monitored are files under a private directory corresponding to the application; alternatively, the first and second electrodes may be,

the files to be monitored are files under a public directory accessible by the application.

4. The method of claim 1, wherein the files that need to be monitored are determined from files that are allowed to be monitored;

the files allowed to be monitored are determined by monitoring state identifiers, the monitoring state identifiers are used for indicating the monitoring state of the files or the directories, and the monitoring state is one of monitoring available, non-monitoring and monitoring available.

5. The method of claim 4, wherein the files that need to be monitored are determined from files that are allowed to be monitored, comprising:

the files to be monitored are determined from the files allowed to be monitored according to an operation instruction, and the operation instruction is used for requesting to execute one of single directory monitoring setting, directory comprehensive monitoring setting, single directory monitoring canceling setting, directory comprehensive monitoring canceling setting, file monitoring setting and file monitoring canceling setting.

6. The method of any of claims 1-5, wherein after the initiating the monitoring thread, the method further comprises:

adding or deleting paths to paths of the files needing to be monitored stored in the monitoring queue.

7. The method of claim 6, wherein adding a new path to the path of the file to be monitored stored in the monitoring queue comprises:

and if all the parent directories of the first directory are allowed to be monitored, executing the request of the first request message, and adding the path of the first directory to the monitoring queue to complete the addition of the files under the first directory to the files needing to be monitored.

8. The method of claim 7, wherein after the adding the path of the first directory to the monitoring queue, the method further comprises:

determining whether a subdirectory exists under the first directory;

and if a first subdirectory exists in the first directory, adding the path of the first subdirectory to the monitoring queue to finish adding the files in the first subdirectory to the files needing to be monitored.

9. The method of claim 6, wherein deleting a path from the paths of the files to be monitored stored in the monitoring queue comprises:

acquiring a second operation instruction, wherein the second operation instruction is used for requesting to cancel monitoring of a second directory;

10. The method of claim 9, wherein after the removing the path of the second directory from the monitoring queue according to the second operation instruction, the method further comprises:

determining whether a subdirectory exists under the second directory;

and if a second subdirectory exists in the second directory, deleting the path of the second subdirectory from the monitoring queue to finish deleting the files in the second subdirectory from the files needing to be monitored.

11. The method according to any one of claims 1-10, wherein after said controlling said process fetches said first event from said event queue to complete monitoring of changes to said target file, said method further comprises:

and carrying out cross-device synchronization on the changed target file.

12. A monitoring device, comprising:

13. An electronic device comprising a processor, a memory, and a computer program or instructions stored on the memory, wherein the processor executes the computer program or instructions to implement the steps of the method of any of claims 1-11.

14. A computer-readable storage medium, characterized in that it stores a computer program or instructions which, when executed, implement the steps of the method of any one of claims 1-11.