Metadata reading method and related equipment thereof
By caching the metadata of the second electronic device in the first electronic device body, the problem of low cross-device metadata reading efficiency is solved, and more efficient file reading speed and performance improvement is achieved.
Patent Information
- Application Number
- CN202311872451.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-12-29
- Publication Date
- 2025-07-08
AI Technical Summary
In the existing distributed file system, when users need to obtain metadata of large amounts of files across devices, the reading process takes a long time and is inefficient, resulting in a slower file reading speed.
By buffering the metadata of the second electronic device in the first electronic device body, cross-device communication is reduced, metadata cache data is read from the local area, and if necessary, then obtained from the second electronic device, and the cache is updated in combination with file changes.
Improves the efficiency and performance of cross-device metadata reading, reduces traffic, and ensures consistency of cached data.
Smart Images

Figure CN120277039A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the technical field of terminals, and specifically relates to a method for reading metadata and related devices. Background Art
[0002] With the booming development of network communication technology, the Internet of Everything has entered people's lives. The basis of the Internet of Everything is that data between different devices can be accessed mutually, and the distributed file system is exactly a technology that provides data consistency among different devices.
[0003] Existing distributed file systems usually include a metadata processor and a data processor. When a user accesses file data, they need to first access the metadata processor across devices to obtain the basic information and data index information of the file, and then access the data processor to obtain the file data.
[0004] However, when a user needs to continuously perform read operations on a large number of files, if each file needs to obtain the corresponding metadata across devices, the process of reading metadata will consume a large amount of time, with low efficiency and reduced file reading speed. Therefore, how to optimize the reading method and improve the reading efficiency has become an urgent problem to be solved. Summary of the Invention
[0005] This application provides a method for reading metadata and related devices, which can reduce cross-device communication by reading metadata cache data from the first electronic device body, thereby achieving the purpose of improving reading efficiency and performance.
[0006] In a first aspect, a method for reading metadata is provided. This method is applied to a first electronic device and includes: in response to a first operation, reading metadata cache data in the first electronic device body; the metadata cache data is a cache object corresponding to a metadata list in a second electronic device in the first electronic device; if there is metadata cache data in the first electronic device body, reading the metadata list from the first electronic device body.
[0007] It should be understood that the first electronic device may refer to Figure 6 the first electronic device 100 in Figure 8 or the third electronic device 300 shown in
[0008] In the embodiments of this application, by caching the metadata of the second electronic device in the first electronic device body, it is possible to directly read the metadata cache data from the first electronic device body during reading, thereby reducing cross-device communication and achieving the purpose of improving reading efficiency and performance.
[0009] In combination with the first aspect, in certain implementations of the first aspect, the method further includes: if there is no such metadata cache data in the first electronic device body, sending an acquisition instruction to the second electronic device, where the acquisition instruction is used to indicate acquiring the metadata list from the second electronic device; receiving the metadata list returned by the second electronic device and storing it.
[0010] It should be understood that the returned metadata list is stored in the metadata cache module in the first electronic device.
[0011] In combination with the first aspect, in certain implementations of the first aspect, the method further includes: receiving a file change notification; the file change notification is used to indicate that after the second electronic device receives and responds to the acquisition instruction to register file monitoring, when it monitors that a file in the second electronic device has changed, a notification returned to the first electronic device; updating the metadata cache data.
[0012] In combination with the first aspect, in certain implementations of the first aspect, the method further includes: when the file change monitored in the second electronic device is an addition, the newly added metadata is carried in the file change notification.
[0013] It should be understood that when a file in the second electronic device changes, only the changed part of the metadata can be communicated and transmitted to the first electronic device, which can not only ensure the consistency of the metadata cache data in the first electronic device and the metadata in the second electronic device, but also reduce the amount of data during communication and avoid transmitting all metadata every time it is read.
[0014] In combination with the first aspect, in certain implementations of the first aspect, the method further includes: storing the metadata cache data in the metadata cache module in the first electronic device body.
[0015] It should be understood that the metadata cache module is Figure 6 the metadata cache module in the distributed file client in the first electronic device shown, or Figure 8 the metadata cache module in the distributed file client in the third electronic device 300 shown.
[0016] In combination with the first aspect, in certain implementations of the first aspect, the method further includes: managing the metadata cache data using a B-tree structure.
[0017] In combination with the first aspect, in certain implementations of the first aspect, when the software system of the first electronic device is an Android architecture, the method further includes: after updating the metadata cache data, notifying the kernel that the old metadata cache data becomes invalid.
[0018] In the embodiment of the present application, the metadata cache module is used to notify the kernel that the metadata cache data between the old or updated metadata becomes invalid. It should be understood that since the kernel of the Android architecture itself also has a cache, when there is an update in the metadata cache module, it is also necessary to notify the kernel that the original cache becomes invalid, that is, the old metadata becomes invalid.
[0019] In combination with the first aspect, in some implementation manners of the first aspect, the method further includes: running a file management application; and mounting the second electronic device in response to the online status of the second electronic device.
[0020] In combination with the first aspect, in some implementation manners of the first aspect, the method further includes: the first operation is an open operation for a directory in the file management application.
[0021] In a second aspect, a metadata reading device is provided, including a unit for executing any method in the first aspect. The device can be a server, a terminal device, or a chip in the terminal device. The device can include an input unit and a processing unit.
[0022] When the device is a terminal device, the processing unit can be a processor, and the input unit can be a communication interface; the terminal device can further include a memory, and the memory is used to store computer program code. When the processor executes the computer program code stored in the memory, the terminal device is caused to execute any method in the first aspect.
[0023] When the device is a chip in the terminal device, the processing unit can be a processing unit inside the chip, and the input unit can be an output interface, a pin, a circuit, etc.; the chip can further include a memory, and the memory can be a memory inside the chip (for example, a register, a cache, etc.), or a memory located outside the chip (for example, a read-only memory, a random access memory, etc.); the memory is used to store computer program code. When the processor executes the computer program code stored in the memory, the chip is caused to execute any method in the first aspect.
[0024] In a possible implementation manner, the memory is used to store computer program code; a processor, the processor executes the computer program code stored in the memory. When the computer program code stored in the memory is executed, the processor is used to execute: in response to a first operation, reading metadata cache data in the first electronic device body; the metadata cache data is a cache object corresponding to a metadata list in the second electronic device in the first electronic device; if there is metadata cache data in the first electronic device body, reading the metadata list from the first electronic device body.
[0025] In a third aspect, a chip system is provided, including: a processor configured to call and run a computer program from a memory, such that a device installed with the chip system executes the first aspect.
[0026] In a fourth aspect, a computer-readable storage medium is provided, which stores computer program code that, when run on an electronic device, causes the electronic device to execute any one of the metadata reading methods in the first aspect.
[0027] In a fifth aspect, a computer program product is provided, which includes: computer program code that, when run on an electronic device, causes the electronic device to execute any one of the metadata reading methods in the first aspect.
[0028] In the embodiments of the present application, by caching metadata in a first electronic device, when a read instruction is received, the metadata cache can be first read from the first electronic device body, reducing cross-device communication and achieving the purpose of improving the efficiency and performance of cross-device metadata reading. When the metadata cache data is not read in the first electronic device, it is obtained from a second electronic device, and a file listener is registered on the second electronic device. In this way, when the file on the second electronic device changes, the metadata cache data in the first electronic device can be updated in a timely manner, with a small amount of data and high efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0029] Figure 1 is an exemplary schematic diagram of metadata information of a file in the embodiments of the present application;
[0030] Figure 2 is an adaptable application scenario diagram provided by the embodiments of the present application;
[0031] Figure 3 is another adaptable application scenario diagram provided by the embodiments of the present application;
[0032] Figure 4 is a hardware system diagram of an electronic device provided by the embodiments of the present application;
[0033] Figure 5 is a software system diagram provided by the embodiments of the present application;
[0034] Figure 6 is a flowchart of a metadata reading method provided by the embodiments of the present application;
[0035] Figure 7 is another software system diagram provided by the embodiments of the present application;
[0036] Figure 8It is a schematic flowchart of another metadata reading method provided by an embodiment of the present application;
[0037] Figure 9 It is an example of a metadata cache object provided by an embodiment of the present application;
[0038] Figure 10 It is a schematic flowchart of yet another metadata reading method provided by an embodiment of the present application;
[0039] Figure 11 It is a schematic diagram of the interface of a first electronic device provided by an embodiment of the present application;
[0040] Figure 12 It is a schematic diagram of the interface of a third electronic device provided by an embodiment of the present application;
[0041] Figure 13 It is a schematic structural diagram of another electronic device provided by an embodiment of the present application;
[0042] Figure 14 It is a schematic structural diagram of yet another electronic device provided by an embodiment of the present application. Detailed implementation manners
[0043] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Among them, in the description of the embodiments of the present application, unless otherwise specified, " / " means "or". For example, A / B may represent A or B; "and / or" in the text is only a description of the association relationship between associated objects, indicating that there can be three relationships. For example, A and / or B may represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of the present application, "a plurality of" means two or more than two.
[0044] It should be understood that the terms "first", "second", etc. in the specification, claims and drawings of the present application are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or units inherent to these processes, methods, products or devices.
[0045] References to "embodiments" in this application mean that specific features, structures, or characteristics described in connection with the embodiments can be included in at least one embodiment of this application. The phrase appears in various places in the specification and does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that the embodiments described in this application can be combined with other embodiments.
[0046] For ease of understanding, the nouns involved in the embodiments of this application are first described.
[0047] 1. File System (FS), a software mechanism in an operating system responsible for managing and storing file information. The functions of the file system include: managing and scheduling the storage space of files, providing the logical structure, physical structure, and storage methods of files; implementing the mapping from file identification to actual address, implementing file control operations and storage operations, implementing file information sharing and providing reliable file confidentiality and protection measures, and providing file security measures.
[0048] 2. Distributed File System (DFS) refers to a file system where the physical storage resources it manages are not necessarily directly connected to the local node, but are connected to distributed nodes through a computer network; or it is a complete hierarchical file system formed by combining several different logical disk partitions or volume labels. DFS provides a logically tree-shaped file system structure for resources located anywhere on the network, making it more convenient for users to access shared files distributed on the network. In short, a distributed file system is a system that organizes multiple storage devices to form a unified file system, enabling users to access and manage the data in these storage devices through a logical path.
[0049] 3. Metadata, data used to describe data or information about information. Metadata can describe the elements or attributes (name, size, data type, etc.) of data, or its structure (length, fields, data columns), or its related data (where it is located, how to connect, owner). The above data is the file data in the file, that is, the data used by users for calculation.
[0050] In the embodiments of this application, according to the different file types, the metadata describing the file included in the metadata information of the file can also be different. Generally, the metadata of a file included in the metadata information of a file can include: file name, file type, file size, modification time, access permission, etc. The metadata information of different types of files can include different metadata. For some files with specific formats, the metadata information of the file can also include more specific metadata.
[0051] Figure 1 This is an exemplary schematic diagram of the metadata information of the files in the embodiments of the present application.
[0052] Exemplarily, as Figure 1 shown in (a) of, for a text document type file: Document1.txt, the metadata information in it may include: file name: Document1.txt, document type: text document, and metadata such as file size, modification time, etc.
[0053] Exemplarily, as Figure 1 shown in (b) of, for a picture file: Picture2.jpg, in addition to the metadata such as file name, document type, file size, modification time, etc., the metadata information in it may also include file-specific metadata of this picture type such as shooting time, resolution, bit depth, width, height, etc.
[0054] Exemplarily, as Figure 1 shown in (c) of, for an audio file: Song3.mp3, in addition to the metadata such as file name, document type, file size, modification time, etc., the metadata information in it may also include file-specific metadata of this audio type such as album, genre, duration, bit rate, etc.
[0055] In the embodiments of the present application, the metadata of the file can be divided into basic information and data index information.
[0056] 4. Mounting, which can also be called distributed storage mounting, refers to mounting the data in the distributed storage system to the computing node, so that the computing node can access and operate on this data as if it were accessing the local file system. Through distributed storage mounting, the computing node can directly read and write the data in the distributed storage system without the need for data transmission through network communication. This method can improve the efficiency and performance of data access, and at the same time facilitate the management and maintenance of data by the computing node. The implementation of distributed storage mounting depends on the distributed file system.
[0057] In the embodiments of the present application, the distributed storage system can indicate the local file system in the second electronic device.
[0058] The above is a simple introduction to the terms involved in the embodiments of the present application, and will not be elaborated below.
[0059] Figure 2 and Figure 3 respectively show some application scenarios applicable to the embodiments of the present application.
[0060] Such as Figure 2As shown, generally, people such as office workers, researchers, and college students need to save a lot of learning materials, research reports, office summaries and other related documents, and these documents are often distributed on different devices such as personal mobile phones, tablets, laptops, and desktop computers. In this way, when users need to use these documents, they often need to use or view files across devices, search for or transfer files across devices, etc. The operations are troublesome and the efficiency is low. In response to this, a distributed file system has emerged. The distributed file system can provide distributed file capabilities, supporting that super terminal devices can access the file system and data from each other.
[0061] Exemplarily, as Figure 3 shown in (a) of Figure 3 when in the near field, the user can directly browse and open the files on the tablet computer (i.e., the second electronic device 200) on the laptop computer (i.e., the first electronic device 100), or, as
[0062] shown in (b) of
[0063] the user can also directly browse and open the files on the tablet computer (i.e., the second electronic device 200) on the mobile phone (i.e., the third electronic device 300).
[0064] However, in the current distributed scenario, when a user accesses cross-device files in the file management application of device A, the user needs to first obtain the metadata of the file across devices and then obtain the file data. When the user needs to continuously perform read operations on a large number of files, if each file needs to obtain the corresponding metadata across the network, the process of reading metadata will consume a lot of time, with low efficiency and reduced reading speed. Therefore, how to optimize the reading method and improve the reading efficiency has become an urgent problem to be solved.
[0065] The first electronic device 100, the second electronic device 200, and the third electronic device 300 provided in the embodiments of the present application can all be mobile phones, tablet computers, personal computers (PCs), personal digital assistants (PDAs), smart watches, netbooks, wearable electronic devices, augmented reality (AR) devices, virtual reality (VR) devices, vehicle-mounted devices, smart cars, robots, smart glasses, smart TVs, etc. The embodiments of the present application do not limit the specific form of this electronic device.
[0066] Taking the electronic device as the first electronic device 100, the second electronic device 200, or the third electronic device 300 as an example, Figure 4 A hardware system of an electronic device applicable to the present application is shown.
[0067] As Figure 4 shown, the electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. Among them, the sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.
[0068] It should be noted that Figure 4 the structure shown does not constitute a specific limitation on the electronic device. In other embodiments of the present application, the electronic device may include more or fewer components than Figure 4 shown, or the electronic device may include a combination of some of the components Figure 4 shown, or the electronic device may include sub-components of some of the components Figure 4 shown. Figure 4The components shown can be implemented in hardware, software, or a combination of software and hardware.
[0069] Processor 110 may include one or more processing units. For example, processor 110 may include at least one of the following processing units: an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and a neural-network processing unit (NPU). Among them, different processing units may be independent devices or integrated devices. The controller can generate operation control signals according to the instruction operation code and timing signals to complete the control of fetching and executing instructions.
[0070] A memory may also be provided in processor 110 for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store the instructions or data that processor 110 has just used or recycled. If processor 110 needs to use the instruction or data again, it can be directly called from the memory. This avoids repeated accesses, reduces the waiting time of processor 110, and thus improves the efficiency of the system.
[0071] In some embodiments, processor 110 may include one or more interfaces. For example, processor 110 may include at least one of the following interfaces: an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (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 SIM interface, and a USB interface.
[0072] Exemplarily, the processor 110 provided by an embodiment of the present application may execute the following method: in response to a first operation, read metadata cache data in the first electronic device body; the metadata cache data is a cache object corresponding to a metadata list in a second electronic device in the first electronic device; if there is metadata cache data in the first electronic device body, read the metadata list from the first electronic device body.
[0073] Figure 4 The connection relationships shown between the various modules are only illustrative and do not constitute a limitation on the connection relationships between the modules of the electronic device. Optionally, the various modules of the electronic device may also adopt a combination of the various connection methods in the above embodiments.
[0074] The wireless communication function of the electronic device may be implemented by devices such as antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modulation and demodulation processor, and baseband processor.
[0075] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be multiplexed to improve the utilization rate of the antennas. For example: Antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.
[0076] The electronic device can implement the display function through the GPU, display screen 194, and application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or change display information.
[0077] The display screen 194 can be used to display images or videos.
[0078] Optionally, the display screen 194 can be used to display images or videos. The display screen 194 includes a display panel. The display panel can adopt a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a mini light-emitting diode (Mini LED), a micro light-emitting diode (Micro LED), a Micro OLED, or a quantum dot light emitting diode (QLED). In some embodiments, the electronic device 100 can include one or N display screens 194, where N is a positive integer greater than 1.
[0079] The electronic device can implement the shooting function through the ISP, the camera 193, the video codec, the GPU, the display screen 194, and the application processor, etc.
[0080] The ISP is used to process the data fed back by the camera 193. For example, when taking a photo, the shutter is opened, and the light passes through the camera and is transmitted to the camera sensor. The optical signal is converted into an electrical signal, and the camera sensor transmits the electrical signal to the ISP for processing and converts it into an image visible to the naked eye. The ISP can perform algorithm optimization on the noise, brightness, and color of the image. The ISP can also optimize parameters such as the exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 193.
[0081] The camera 193 (which can also be referred to as a lens) is used to capture still images or videos. It can be triggered to turn on through application instructions to achieve the photographing function, such as capturing images of any scene. The camera may include components such as an imaging lens, a filter, and an image sensor. The light emitted or reflected by an object enters the imaging lens, passes through the filter, and finally converges on the image sensor. The imaging lens is mainly used to converge and form an image of the light emitted or reflected by all objects in the photographing perspective (which can also be referred to as the scene to be photographed, the target scene, or the scene image that the user expects to photograph); the filter is mainly used to filter out the excess light waves in the light (such as light waves other than visible light, such as infrared); the image sensor can be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The image sensor is mainly used to perform photoelectric conversion on the received optical signal, convert it into an electrical signal, and then transfer the electrical signal to the ISP to convert it into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in standard formats such as RGB and YUV.
[0082] Exemplarily, the digital signal processor is used to process digital signals. In addition to being able to process digital image signals, it can also process other digital signals. For example, when the electronic device is selecting a frequency point, the digital signal processor is used to perform Fourier transform on the frequency point energy, etc.
[0083] Exemplarily, the video codec is used to compress or decompress digital videos. The electronic device 100 can support one or more video codecs. In this way, the electronic device 100 can play or record videos in multiple encoding formats, such as: Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, and MPEG4.
[0084] Exemplarily, the gyroscope sensor 180B can be used to determine the motion posture of the electronic device 100. In some embodiments, the angular velocity of the electronic device 100 around three axes (i.e., the x-axis, y-axis, and z-axis) can be determined through the gyroscope sensor 180B. The gyroscope sensor 180B can be used for anti-shake during photographing. For example, when the shutter is pressed, the gyroscope sensor 180B detects the angle of jitter of the electronic device 100, calculates the distance that the lens module needs to compensate according to the angle, and makes the lens offset the jitter of the electronic device 100 through reverse movement to achieve anti-shake. The gyroscope sensor 180B can also be used in scenarios such as navigation and motion-sensing games.
[0085] Exemplarily, the acceleration sensor 180E can detect the magnitude of the acceleration of the electronic device 100 in various directions (generally the x-axis, y-axis, and z-axis). When the electronic device 100 is stationary, the magnitude and direction of gravity can be detected. The acceleration sensor 180E can also be used to identify the posture of the electronic device 100 and serve as an input parameter for application programs such as horizontal and vertical screen switching and pedometers.
[0086] Exemplarily, the distance sensor 180F is used to measure distance. The electronic device 100 can measure distance through infrared or laser. In some embodiments, for example, in a shooting scenario, the electronic device 100 can use the distance sensor 180F to measure distance to achieve rapid focusing.
[0087] Exemplarily, the ambient light sensor 180L is used to sense the ambient light brightness. The electronic device 100 can adaptively adjust the brightness of the display screen 194 according to the sensed ambient light brightness. The ambient light sensor 180L can also be used to automatically adjust the white balance during photography. The ambient light sensor 180L can also cooperate with the proximity light sensor 180G to detect whether the electronic device 100 is in a pocket to prevent accidental touch.
[0088] Exemplarily, the fingerprint sensor 180H is used to collect fingerprints. The electronic device 100 can use the collected fingerprint characteristics to implement functions such as unlocking, accessing application locks, taking pictures, and answering incoming calls.
[0089] Exemplarily, the touch sensor 180K, also known as a touch control device. The touch sensor 180K can be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, which is also called a touch control screen. The touch sensor 180K is used to detect touch operations acting on or near it. The touch sensor 180K can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 194. In some other embodiments, the touch sensor 180K can also be disposed on the surface of the electronic device 100 and be located at a different position from the display screen 194.
[0090] The hardware system of the electronic device has been described in detail above. Above the above-mentioned hardware, an operating system is running. The operating system at the operating system layer can be any one or more computer operating systems that implement business processing through processes. For example, Linux operating system, Unix operating system, Android operating system, iOS operating system, or Windows operating system, etc. Application programs can be installed and run on the operating system.
[0091] Combined with Figure 3As shown in (a) therein, taking the first electronic device 100 running the Windows operating system and the second electronic device 200 running the Android operating system as an example, Figure 5 is a software system diagram of a first electronic device 100 and a second electronic device 200 provided in an embodiment of the present application.
[0092] In some embodiments, such as Figure 5 shown, on the side of the first electronic device 100, the Windows system is generally divided into a kernel mode and a user mode. Among them, the kernel mode and the user mode can run at different privilege levels of the central processing unit (CPU). For example, the kernel mode can run at layer 0 of the CPU, and the user mode can run at layer 3 of the CPU.
[0093] Each layer of the Windows system is composed of several components. As a whole, the operation of the Windows system depends on the upper-layer components calling the lower-layer components. Each layer of components has a fixed interface for the upper layer to call. If the upper layer needs to perform a permission change operation, it needs to request the lower layer.
[0094] Such as Figure 5 shown, in the user mode, the application layer or the so-called application layer can include a file management application and a distributed file client. In addition, it can also include: a global favorites application, a music application, a video application, a teleconference application, a game application, etc. The embodiments of the present application do not limit this.
[0095] Optionally, in the embodiments of the present application, the distributed file client can include a message sending and receiving module A, a metadata management module, a Fuse adaptation layer, and a file management module. Among them, the metadata management module can include a metadata cache module. Of course, the distributed file client can also include other modules. The embodiments of the present application do not limit this. The specific functions of each module can refer to the subsequent introduction of Figure 7 and will not be elaborated here.
[0096] Optionally, the application layer can call the application programming interface (API) in its corresponding subsystem (such as Win32, POSIX, OS / 2, etc.). The application layer can call system service functions through the API, and then call the corresponding services. Applications are relatively isolated from each other, and their communication needs to be completed through the system. The operating system can provide some basic inter-process communication to support the interaction between applications in the application layer. Among them, the POSIX standard defines the interface standard that the operating system should provide for applications, and it is the general name of a series of API standards defined by IEEE for software to run on various UNIX operating systems.
[0097] Exemplarily, the Windows subsystem can convert API functions into Native API to achieve compatibility with applications. Function calls in Native API are converted into system service function calls and enter the kernel mode, and are further passed down to implement corresponding functions.
[0098] It should be understood that the kernel mode of the Windows system can implement the basic mechanisms of the operating system. The code running in the kernel mode is all core code, and these codes will not be attacked maliciously. Applications running in the user mode are the least secure and vulnerable to attacks, so the application permissions are restricted.
[0099] In the kernel mode of the Windows system, the kernel layer (kernel), also known as the micro-kernel, contains basic operating system primitives and functions, such as threads and processes, thread scheduling, handling of terminals and exceptions, synchronization objects, and various synchronization mechanisms.
[0100] In the kernel mode of the Windows system, the Dokan library is equivalent to the Fuse user-mode file system framework on the Windows system. The Dokan library contains the user-mode dynamic link library (Dokan.dll) and the kernel-mode driver (Dokan1.sys). The file system created using Dokan can be called a file system program (such as Figure 5As shown in the distributed file client), at this time, file operation requests (such as create File, Read File, Write File) proposed by a program (such as a file management application) will be sent to the kernel for execution. The kernel will then continue to send the request to Dokan.sys; the file system program can use the functions provided by Dokan.dll to register callback functions (i.e., operation implementation functions) into Dokan.sys. After receiving the request, Dokan.sys calls the operation implementation function and then sends the result back to the program that proposed the request. It should be understood that Dokan.sys is equivalent to an agent running in kernel mode and serves as a bridge between the program that proposes the request and the file system program that implements various operations.
[0101] In some embodiments, as Figure 5 shown, on the side of the second electronic device 200, for the Android system, the layered architecture can divide the software into several layers, and each layer has a clear role and division of labor. The layers communicate with each other through software interfaces. For example, the Android system can be divided into three layers, from top to bottom, namely the application layer, the application framework layer (application framework), and the kernel layer.
[0102] Among them, the application layer can include a series of application packages. For example, the application layer can include a distributed file server. Of course, the application layer can also include other applications such as a global collection application, a gallery APP, a camera APP, etc., and the embodiments of the present application do not make any restrictions on this.
[0103] Optionally, in the embodiments of the present application, the distributed file server can include a second message receiving and sending module and a file operation processing module, and the file operation processing module can include a file monitoring module. Of course, the distributed file server can also include other modules, and the embodiments of the present application do not make any limitations on this. The specific functions of each module can be further referred to the subsequent introduction for Figure 6 which will not be elaborated here.
[0104] The application framework (or called the framework layer) provides application programming interfaces (application programming interface, API) and programming frameworks for the applications in the application layer. The application framework layer includes some predefined functions. In the embodiments of the present application, the application framework layer can include POSIX interfaces.
[0105] The kernel layer is the layer between the hardware and the software. In the embodiments of the present application, the kernel layer can include a local file system, etc.
[0106] It should be understood that the first electronic device can perform data transmission with the message receiving and sending module in the distributed file server module in the application layer of the second electronic device through the message receiving and sending module in the distributed file client module in the application layer, so as to realize file sharing between the first electronic device and the second electronic device.
[0107] It should be noted that in the embodiments of the present application, the first electronic device is taken as an example of a Windows system, and the second electronic device is taken as an example of an Android system for description. However, the basic principle also applies to electronic devices based on other operating systems.
[0108] Combined with Figure 3 as shown in (b) therein, taking the third electronic device 300 and the second electronic device 200 both running the Android system as an example, Figure 7 shows a software system diagram of a third electronic device 300 and a second electronic device 200 provided by the embodiments of the present application.
[0109] As Figure 7 shown, the software system architecture of the second electronic device 200 is the same as the above introduction and will not be elaborated here.
[0110] In some embodiments, on the side of the third electronic device 300, the Android system in the third electronic device 300 is also divided into three layers, from top to bottom are the application layer, the application framework layer, and the kernel layer.
[0111] Among them, the application layer in the third electronic device 300 also includes file management and a distributed file client. For the introduction of the distributed file client, reference can be made to the description of the distributed file client included in the first electronic device 100 and will not be elaborated here.
[0112] The application framework layer may include a POSIX interface.
[0113] The kernel layer may include a kernel and a Fuse user-space file system framework. The kernel can refer to the introduction of the kernel in the above first electronic device 100. The Fuse user-space file system framework provides a user-space dynamic link library libFuse.so and a kernel-space driver Fuse.ko.
[0114] It should be understood that the third electronic device can perform data transmission with the message receiving and sending module in the distributed file server module in the application layer of the second electronic device through the message receiving and sending module in the distributed file client module in the application layer, so as to realize file sharing between the third electronic device and the second electronic device.
[0115] It should be noted that the embodiments of the present application are described by taking both the third electronic device and the second electronic device as Android systems as examples, but the basic principle thereof is also applicable to electronic devices based on other operating systems.
[0116] Embodiment 1
[0117] Next, taking Figure 3 the first electronic device shown in (a) in Figure 5 as a laptop computer and the second electronic device as a tablet computer, and taking the operating system shown in
[0118] Figure 6 as an example, the metadata reading method provided by the embodiments of the present application will be briefly described. Figure 6 As shown in
[0119] Figure 15, the metadata reading method 600 is applied to the first electronic device and the second electronic device described above. The metadata reading method 600 may include a mounting stage - a first acquisition stage - a second acquisition stage. The processes included in each stage will be introduced separately below.
[0120] S601. Initialize the Fuse adaptation layer in the first electronic device.
[0121] It should be understood that the initialization is used to clear the old and existing nodes for mounting a new root node.
[0122] S602. The Fuse adaptation layer mounts the root node to Dokan.
[0123] S603. Dokan mounts the root node to the kernel layer.
[0124] S604. In response to the second electronic device going online, the file management application in the first electronic device issues a acquisition instruction to the message receiving and sending module A in the distributed file client.
[0125] The method for the second electronic device to go online is any method provided by the prior art, and the present application does not make a limitation in this regard.
[0126] The acquisition instruction is used to indicate to acquire the mountable path of the second electronic device. The acquisition instruction may also carry parameters, and the parameters may include the device ID of the second electronic device, etc. Since the device ID of the second electronic device is carried in the parameters, when the file management application in the first electronic device issues an acquisition instruction to the message receiving and sending module C in the distributed file client, the message receiving and sending module C can know the target device for acquiring the mountable path based on the device ID of the second electronic device carried in the parameters.
[0127] Optionally, the parameter carried in the acquisition instruction may further include the device ID of the first electronic device, which is not limited in the embodiments of the present application.
[0128] S605. The message sending and receiving module A in the distributed file client sends an acquisition instruction to the message sending and receiving module B in the distributed file server of the second electronic device.
[0129] S606. After receiving the acquisition instruction, the message sending and receiving module B sends a list of mountable paths to the message sending and receiving module A.
[0130] The list of mountable paths includes one or more mountable paths in the second electronic device.
[0131] S607. The message sending and receiving module A sends the returned list of mountable paths to the file management application.
[0132] Thus, the second electronic device can send the list of mountable paths to the file management application in the first electronic device based on the device ID of the first electronic device. In this way, it is equivalent that the first electronic device obtains the list of mount paths of the peer (i.e., the second electronic device).
[0133] S608. The file management application in the first electronic device sends a mount request to the message sending and receiving module A.
[0134] Among them, the mount request is used to request to mount the second electronic device to the first electronic device, which is convenient for opening and browsing the files of the second electronic device on the first electronic device. The mount request may carry parameters, and the parameters may include the device ID of the second electronic device, the mount path of the second electronic device, the local mount path, etc.
[0135] Exemplarily, the mount path of the second electronic device may be: " / sdcard"; the local mount path may be expressed as: "D:\Device ID of the second electronic device" or "Network location\Device ID of the second electronic device". If the device ID of the second electronic device is 000010, the local mount path may be expressed as: "D:\000010" or "Network location\000010".
[0136] It should be noted that most of the user's data is saved in the sdcard of the second electronic device. For example, albums, documents, etc. are all saved in the directory of the sdcard. Therefore, the mount path of the second electronic device may be: " / sdcard", and the mount request sent by the first electronic device to the second electronic device may request to mount this path.
[0137] Here, it should be understood that the mountable path is default selected by the upper-layer service and does not involve user triggering. For example, in a file management application, after detecting that the second electronic device is online, based on the returned list of mountable paths, a certain mountable path corresponding to the file management service by default can be selected therefrom, such as " / sdcard" as described above; this " / sdcard" is the service mount path corresponding to the file management service.
[0138] It should be understood that for different upper-layer services, the default corresponding mountable paths in the second electronic device can be different. For example, for the global favorites application in the first electronic device, after detecting that the second electronic device is online, based on the returned list of mountable paths, another mountable path corresponding to the global favorites service by default can be selected therefrom.
[0139] S609. The message receiving and sending module A in the first electronic device sends a mount request to the message receiving and sending module B in the distributed file server of the second electronic device.
[0140] S610. In response to the mount request, the first electronic device performs mounting, and after successful mounting, the message receiving and sending module B returns a mount success feedback message to the message receiving and sending module A.
[0141] Optionally, if the message receiving and sending module A does not receive the mount success feedback message returned by the message receiving and sending module B, it can send the mount request to the message receiving and sending module B again to attempt to trigger the mounting again. It should be understood that the message receiving and sending module A can send multiple mount requests to the message receiving and sending module B until the mounting is successful.
[0142] Optionally, if the message receiving and sending module A does not receive the mount success feedback message returned by the message receiving and sending module B, it can return a mount failure feedback message to the file management application in the first electronic device to trigger the mounting automatically again through the application.
[0143] S611. After the message receiving and sending module A in the second electronic device receives the feedback message, it points the mount path (or the service mount path) to the disk path.
[0144] Exemplarily, Figure 11 is a schematic diagram of the interface in the first electronic device provided in the embodiment of the present application. Pointing the service mount path to the disk path can indicate, as shown in (a) of Figure 11 linking "Network Location\Device ID of the second electronic device" and "C:\user\username\PCManger\dfs\default\Device ID of the second electronic device".
[0145] S612. The message receiving and sending module A returns a mount success feedback message to the file management application.
[0146] In an embodiment of the present application, a file management application in a first electronic device mounts a second electronic device through a distributed file system. Thus, the distributed file system included in the first electronic device can be referred to as a distributed file client, and the distributed file system included in the second electronic device can be referred to as a distributed file server. After successful mounting, the user can browse and open files on the second electronic device through the distributed file client in the file management application on the first electronic device.
[0147] Phase II: The first acquisition phase
[0148] S621. The first electronic device displays a first interface and receives a user operation.
[0149] Optionally, the user operation may indicate a user operation on a directory included in the first interface.
[0150] Exemplarily, as shown in (a) of Figure 11 , the first interface is the main interface of the file management application; in the first interface, a directory of the successfully mounted second electronic device may be displayed, such as the directory P1 in the interface shown in (a) of Figure 11 . The user operation on the directory included in the first interface may indicate a user operation on the directory P1 under the mounting path.
[0151] For example, the user operation may indicate a double-click operation on the directory by the user using a mouse. Or, the user operation may also be other operations such as a voice operation or an air gesture operation for indicating to open the directory P1, which is not limited in the embodiment of the present application.
[0152] Exemplarily, the first interface may be the main interface of the file management application, and the user operation may indicate a double-click operation on "Network Location\Device ID of the Second Electronic Device\DCIM", where DCIM indicates the file directory corresponding to the photo album in the second electronic device.
[0153] S622. In response to the user operation, the file management application sends a read instruction to message receiving and sending module A of the distributed file client. The read instruction is used to indicate opening a directory, or in other words, indicating reading metadata of the directory corresponding to the user operation.
[0154] Among them, the read instruction may carry parameters, and the parameters may include: a parent directory, such as "Network Location / Device ID of the Second Electronic Device". In one embodiment, the parameter may further include a folder name: "DCIM".
[0155] Optionally, S622 may include the following S6221 to S6225.
[0156] S6221. In response to a user operation, the file management application calls a file library function to traverse a directory. Specifically, the file management application calls the POSIX readdir interface to traverse the directory triggered by the user operation and find the file object corresponding to the directory.
[0157] S6222. The file library function triggers a kernel search and sends a read instruction to the kernel.
[0158] That is, when the upper-layer file management application browses a directory, it directly calls the file library function interface to traverse the directory. That is, the upper-layer service calls the system's file library function, and the readdir interface will trigger a search for the corresponding file object in the kernel.
[0159] It should be understood that the file object refers to the metadata cache data corresponding to the triggered directory.
[0160] S6223. The kernel uses Dokan to call the Fuse adapter layer to search, that is, the kernel sends a read instruction to Dokan.
[0161] S6224. After receiving the read instruction, Dokan sends the read instruction to the Fuse adapter layer.
[0162] S6225. The Fuse adapter layer sends a read instruction to message transceiver module A.
[0163] S623. After receiving the read instruction, message transceiver module A instructs to read metadata cache data from the metadata cache module. At this time, if no metadata cache data is read, that is, when there is no metadata cache data in the metadata cache module, then S624 to S628 are executed; if metadata cache data is read, that is, when there is metadata in the metadata cache module, then S629 is executed.
[0164] Specifically, based on S6224, when a service (such as a file management application) calls message transceiver module A, message transceiver module A reads metadata cache data from the metadata cache module.
[0165] The metadata cache data indicates the metadata stored in the metadata cache module.
[0166] Exemplarily, such as Figure 9As shown in the figure, in an embodiment of the present application, a metadata object is an iNode, and the basic information of the file is stored in the iNode. Among them, the basic information may include ino (iNode-number): the unique identifier of the metadata; name: name; the ID of each user, such as including User ID (UID) and Group ID (GID); utime: modification time and other information. It should be noted that the generation of ino is to generate a unique ino from the hash value of the parent directory address and the name; in addition, UID and GID respectively correspond to the two attributes of the file owner and the owning group, and UID uses root and GID / Android / data: ext_data_rw, / Android / obb is ext_obb_rw, and the others are managed by media_rw.
[0167] The metadata cache object is a MetaNode object. The ino in the MetaNode object can be used to find the corresponding metadata information. The distributed file uses map<ino, iNode*> to manage the mapping relationship between ino and INode. At the same time, map<ino, MetaNode*> is also used to manage the mapping relationship between ino and MetaNode. In the MetaNode object, map<string, MetaNode*> children is used to save the mapping relationship between the subdirectory name and the subdirectory. That is, the metadata cache uses a B-tree structure to manage the cache, and the root node is assigned a fixed ino. When traversing the subdirectory, the subdirectory information can be found through the name in the map.
[0168] S624. When no metadata cache data is read, that is, when there is no cache in the metadata cache module, the first electronic device sends a fetch instruction to the message receiving and sending module B in the second electronic device through the message receiving and sending module A.
[0169] That is, the message receiving and sending module A in the distributed file client sends a fetch instruction to the message receiving and sending module B in the distributed file server. The fetch instruction is used to indicate to fetch metadata from the second electronic device.
[0170] Optionally, fetching metadata indicates fetching the metadata of all child nodes under the directory accessed by the user.
[0171] Among them, the fetch instruction can carry parameters, and the carried parameters can correspond to the parameters in the read instruction.
[0172] For example, the parameters carried in the fetch instruction may include: / sdcard.
[0173] For another example, the parameter carried in the acquisition instruction may include: / sdcard / DCIM. " / sdcard" is the mounting path corresponding to the second electronic device, and DCIM is the folder name included in the parameter of the read instruction.
[0174] S625. In the second electronic device, the message receiving and sending module B sends an acquisition instruction to the local file system.
[0175] It should be understood that all metadata is stored in the local file system of the second electronic device.
[0176] S626. After the local file system in the second electronic device receives the acquisition instruction, based on the parameter carried in the acquisition instruction, it returns the corresponding metadata list to the message receiving and sending module B.
[0177] The metadata list includes one or more metadata.
[0178] It should be understood that after receiving the acquisition instruction, the message receiving and sending module B can call the file library function to obtain the metadata list related to the instruction and return the obtained metadata list to the first electronic device.
[0179] S627. The message receiving and sending module B sends the metadata list to be stored in the metadata cache module of the distributed file client in the first electronic device.
[0180] S628. The metadata cache module sends the metadata list to the file management application.
[0181] S629. When the metadata cache data is read, that is, when there is metadata in the metadata cache module, the metadata cache module, based on the read instruction, sends the corresponding metadata list in the cache to the file management application.
[0182] Regarding S628 and S629, as Figure 6 shown, whether it is the metadata list returned from the second electronic device received or the metadata list read from the metadata cache module, the metadata cache module can send the metadata list to the Fuse adaptation layer, the Fuse adaptation layer sends the metadata list to Dokan, Dokan sends the metadata list to the kernel, and the kernel then sends the metadata list to the file management application through the file library function.
[0183] Exemplarily, in response to a double-click operation by the user on the first electronic device for the directory P1 included in the display interface, as Figure 11As shown in (b) therein, the first electronic device can return the metadata list read from the metadata cache module to the file management application by reading. For example, the metadata list may include metadata corresponding to 12 subdirectories such as "video", "installation package", "picture", "document", etc. It should be noted that this metadata list is not displayed on the display interface, that is, the user is unaware of it. Optionally, subsequently, when the file management application sends a file acquisition instruction to the message receiving and sending module B through the file management module and the message receiving and sending module A, the file data corresponding to these 12 subdirectories can be returned and displayed on the first electronic device as shown in Figure 11 the content shown in (b) therein.
[0184] It should be understood that when the user performs the first operation to read the directory after mounting, the metadata cache module may not store any metadata. At this time, the first electronic device can execute S624 to S628 to obtain the metadata list from the second electronic device for the first time across devices. When the user performs the second or Nth operation to read the directory, the metadata list may already be stored in the metadata cache module. Therefore, the first electronic device can execute S629, no longer perform cross-device acquisition, but directly read the metadata list from the local metadata cache module, thereby achieving the purpose of reducing cross-device communication and improving the reading efficiency and performance.
[0185] In addition, when there is no metadata cache in the metadata cache module, after S626, the method provided in the embodiment of the present application may further include:
[0186] S631: The message receiving and sending module B in the second electronic device sends a registration monitoring instruction to the file monitoring module.
[0187] This registration monitoring instruction is used to register the monitoring of file changes corresponding to the directory and its subdirectories included in the parameter with the file monitoring module based on the parameter carried in the acquisition instruction.
[0188] In the embodiment of the present application, the file operation processing module may include a file monitoring module. The file operation processing module can be used to obtain the metadata list from the local file system of the second electronic device, and can also be used to implement the monitoring of metadata through the file monitoring module.
[0189] S632: After registration, the file monitoring module returns a feedback message indicating successful monitoring to the message receiving and sending module B.
[0190] Optionally, after S632, the method provided in the embodiment of the present application may further include:
[0191] S633. When a file in the local file system of the second electronic device changes, the local file system sends a message to the file monitoring module, which is used to notify the file monitoring module that the file in the local file system has changed.
[0192] S634. After receiving the message, the file monitoring module obtains new metadata from the local file system.
[0193] S635. The local file system returns the new metadata to the file monitoring module.
[0194] S636. The file monitoring module sends a file change notification to Message Sending / Receiving Module B. The file change notification can carry parameters, which can include directory, change event, new file name, etc.
[0195] S637. Message Sending / Receiving Module B sends the file change notification to Message Sending / Receiving Module A in the first electronic device.
[0196] S638. Based on the file change notification, Message Sending / Receiving Module A instructs the metadata cache module to update the metadata cache.
[0197] S639. After the metadata cache module finishes the update, it feeds back a message indicating successful update to Message Sending / Receiving Module B.
[0198] Exemplarily, for example, previously in response to the user's double-click operation, the file management application in the first electronic device opened the album directory, and the second electronic device monitored the album directory. When the user takes a new photo using the second electronic device, the file monitoring module in the second electronic device can monitor that the file has changed. At this time, the file monitoring module can notify Message Sending / Receiving Module B of this file change in real time; Message Sending / Receiving Module B then notifies Message Sending / Receiving Module A of the first electronic device of the file change. After receiving the notification, the first electronic device updates the metadata cache in the metadata cache module based on the data carried in the notification.
[0199] Exemplarily, the parameters carried in the notification can include directory: " / sdcard / DCIM / ", change event: "newly added"; the new file name can include: "new file name: 123.jpg" and the corresponding metadata of this name.
[0200] It should be understood that the above is an example for the newly added event. The file change event can also include: modification, deletion, etc. The change process for each event is similar to the above and can refer to the above description, which will not be elaborated here.
[0201] In the embodiment of the present application, since file listening is registered on the side of the distributed file server, when the text in the server changes, it can be notified to the distributed file client in real time, and the cache content in the metadata cache module included in the distributed file client is updated. Thus, in the subsequent process of continuously responding to user operations to obtain the cache, the content in the metadata cache module can be kept consistent with the metadata content on the side of the distributed file server, avoiding data mismatch errors.
[0202] In addition, each time a file on the side of the distributed file server changes, only the changed metadata content needs to be updated to the metadata cache module on the side of the distributed file client. The amount of data to be changed is small, the efficiency is high, and the energy consumption is small.
[0203] Phase Three: The Second Acquisition Phase
[0204] S641. The first electronic device displays the second interface and receives a user operation.
[0205] Optionally, the user operation may indicate a user operation on the local directory included in the first interface.
[0206] Exemplarily, as shown in (a) of Figure 11 , the first interface is the main interface of the file management application; in the first interface, the local directory of the first electronic device can be displayed, such as P2 in the interface shown in (a) of Figure 11 . The user operation on the local directory included in the first interface may indicate a user operation on directory P2.
[0207] For example, the user operation may indicate a double-click operation on the directory by the user using the mouse. Or, the user operation may also be other operations such as a voice operation or an air gesture operation that indicate opening directory P2. The embodiment of the present application does not limit this.
[0208] Exemplarily, the first interface may be the main interface of the file management application, and the user operation may indicate a double-click operation on "C:\Software", where Software indicates the file directory corresponding to the system software in the first electronic device.
[0209] S642. In response to the user operation, the file management application sends a read instruction to the file library function.
[0210] Among them, the read instruction may carry parameters, and the parameters may include: the parent directory, such as "C:\"; in one embodiment, the parameters may also include the folder name: "Software".
[0211] S643. The file library function sends a read instruction to the kernel, and this read instruction is used to indicate opening a directory, or in other words, to indicate reading the metadata of the directory corresponding to the user operation.
[0212] S644. The kernel returns the corresponding metadata list to the file library function.
[0213] S645. The file library function gives the metadata list to the file management application.
[0214] In the embodiment of the present application, by caching the metadata in the first electronic device, when a read instruction is received, the metadata cache can be first read from the first electronic device body, reducing cross-device communication and achieving the purpose of improving the cross-device metadata reading efficiency and performance. When the metadata cache data is not read in the first electronic device, it is obtained from the second electronic device, and a file monitor is registered on the second electronic device. In this way, when the file on the second electronic device changes, the metadata cache data in the first electronic device can be updated in a timely manner, with a small amount of data and high efficiency.
[0215] Embodiment 2
[0216] Next, taking Figure 3 the third electronic device shown in (b) as a mobile phone and the second electronic device as a tablet computer, and taking the Figure 7 operating system shown as an example, the metadata reading method provided by the embodiment of the present application will be briefly described.
[0217] Figure 8 shows a schematic diagram of a metadata reading method provided by the embodiment of the present application. As Figure 8 shown, this metadata reading method 800 is applied to the above-mentioned third electronic device 300 and second electronic device 200, and both the third electronic device 300 and the second electronic device are Android systems. This metadata reading method 800 may include a mounting stage - a first acquisition stage - a second acquisition stage, and the processes included in each stage will be introduced separately below.
[0218] Stage 1: Mounting stage
[0219] S801. The Fuse adaptation layer in the third electronic device is initialized.
[0220] It should be understood that the initialization is used to clear the old and existing nodes for mounting a new root node.
[0221] S802. The Fuse adaptation layer mounts the root node to the Fuse user-mode file system framework.
[0222] S803. The Fuse user-mode file system framework mounts the root node to the kernel layer.
[0223] S804. In response to the second electronic device going online, the file management application in the third electronic device sends an acquisition instruction to Message Receiving and Sending Module C in the distributed file client.
[0224] The method for the second electronic device to go online is any method provided by the prior art, and the present application does not make any limitation in this regard.
[0225] The acquisition instruction is used to indicate the acquisition of the mountable path of the second electronic device. The acquisition instruction may also carry parameters, which may include the device ID of the third electronic device, the device ID of the second electronic device, etc. Since the device ID of the second electronic device is carried in the parameters, when the file management application APP in the third electronic device sends an acquisition instruction to Message Receiving and Sending Module C in the distributed file client, Message Receiving and Sending Module C can know the target device for acquiring the mountable path based on the device ID.
[0226] Optionally, the parameters carried by the acquisition instruction may also include the device ID of the first electronic device, and the embodiments of the present application do not make any limitation in this regard.
[0227] S805. Message Receiving and Sending Module C in the distributed file client sends the acquisition instruction to Message Receiving and Sending Module B in the distributed file server in the second electronic device.
[0228] S806. After receiving the acquisition instruction, Message Receiving and Sending Module B sends a list of mountable paths to Message Receiving and Sending Module C.
[0229] The list of mountable paths includes one or more mountable paths of the second electronic device.
[0230] S807. Message Receiving and Sending Module C sends the returned list of mountable paths to the file management application.
[0231] Thus, the second electronic device can send the list of mountable paths to the file management application in the third electronic device based on the device ID of the first electronic device. In this way, it is equivalent to the third electronic device obtaining the list of mountable paths of the peer (i.e., the second electronic device).
[0232] S808. The file management application in the third electronic device sends a mount request to Message Receiving and Sending Module C.
[0233] Among them, the mount request is used to request to mount the second electronic device to the third electronic device, which is convenient for opening and browsing the files of the second electronic device on the third electronic device. The mount request may carry parameters, which may include the device ID of the second electronic device, the mount path of the second electronic device, the local mount path, etc.
[0234] Exemplarily, the mounting path of the second electronic device may be: " / sdcard"; the local mounting path may be: "Other Devices\Device ID of the second electronic device". If the device ID of the second electronic device is 000010, the local mounting path may be expressed as: "Other Devices\000010".
[0235] It should be noted that most of the user's data is saved in the sdcard of the second electronic device. For example, albums, documents, etc. are all saved in the sdcard directory. Therefore, the mounting path of the second electronic device can be defaulted to: " / sdcard", and the mounting request sent by the third electronic device to the second electronic device can default to request to mount this path.
[0236] Here, it should be understood that the mountable path is default selected by the upper-layer service and does not involve user triggering. For example, in a file management application, after detecting that the second electronic device is online, based on the returned list of mountable paths, a certain mountable path default corresponding to the file management service can be selected from it, such as the aforementioned " / sdcard"; this " / sdcard" is the service mounting path corresponding to the file management service.
[0237] It should be understood that for different upper-layer services, the default corresponding mountable paths in the second electronic device may be different. For example, for the global favorite application in the third electronic device, after detecting that the second electronic device is online, based on the returned list of mountable paths, another mountable path default corresponding to the global favorite service can be selected from it.
[0238] S809. The message receiving and sending module C in the third electronic device sends a mounting request to the message receiving and sending module B in the distributed file server of the second electronic device.
[0239] S810. In response to the mounting request, the third electronic device mounts, and after the mounting is successful, the message receiving and sending module B returns a feedback message of successful mounting to the message receiving and sending module C.
[0240] S809 and S810 can refer to the above S609 and S610 and will not be elaborated here.
[0241] S811. After the message receiving and sending module C in the second electronic device receives the feedback message, it points the mounting path (or the service mounting path) to the disk path.
[0242] Exemplarily, Figure 12 is a schematic diagram of the interface in the third electronic device provided by the embodiments of the present application. As Figure 12 shown in (a) of, in response to a click operation on the file management application displayed on the desktop, the third electronic device may display as Figure 12The main interface of the file management application shown in (b) of []. Assume that the second electronic device is Honor 100Pro, point the service mounting path to the disk path, and link "Other Devices\Device ID of the Second Electronic Device" and " / mnt / appFuse / dfs / default / Device ID of the Second Electronic Device".
[0243] S812. The message receiving and sending module C of the file management application returns a feedback message indicating successful mounting to the file management application.
[0244] In the embodiment of the present application, the file management application in the third electronic device mounts the second electronic device through the distributed file system. Thus, the distributed file system included in the third electronic device can be referred to as a distributed file client, and the distributed file system included in the second electronic device can be referred to as a distributed file server. After successful mounting, the user can browse and open the files on the second electronic device through the distributed file client in the file management application of the third electronic device.
[0245] Phase II: The first acquisition phase
[0246] S821. The third electronic device displays the third interface and receives a user operation on the third interface.
[0247] Optionally, the user operation may indicate a user operation on the directory included in the third interface.
[0248] Exemplarily, as Figure 12 shown in (c) of [], the third interface is the main interface of the file management application; in the third interface, the directory of the successfully mounted second electronic device can be displayed, such as Figure 12 the directory P3 in the interface shown in (a) of []. The user operation on the directory included in the third interface may indicate a user operation on the directory P3 under the mounting path.
[0249] For example, the user operation may indicate a click operation by the user on the directory. Or, the user operation may also be other operations such as a voice operation or an air gesture operation for indicating to open the directory P3, and the embodiment of the present application does not limit this.
[0250] Exemplarily, the third interface may be the main interface of the file management application, and the user operation may indicate a double-click operation on "Other Devices\Device ID of the Second Electronic Device\DCIM", where DCIM indicates the file directory corresponding to the album in the second electronic device.
[0251] S822. In response to the user operation, the file management application sends a read instruction to the message receiving and sending module C of the distributed file client, and the read instruction is used to indicate to open the directory, or in other words, to indicate to read the metadata of the directory corresponding to the user operation.
[0252] Among them, the read instruction can carry parameters, and the parameters can include: the parent directory, such as "Other Devices / Device ID of the Second Electronic Device"; in one embodiment, the parameters can also include the folder name: "DCIM".
[0253] Optionally, S822 may include the following S8221 to S8225.
[0254] S8221. In response to a user operation, the file management application calls the file library function to traverse the directory. Specifically, the file management application calls the POSIX readdir interface to traverse the directory triggered by the user operation to find the file object corresponding to the directory.
[0255] S8222. The file library function triggers the kernel to search and sends a read instruction to the kernel.
[0256] That is, when the upper-layer file management application browses the directory, it directly calls the file library function interface to traverse the directory. That is, the upper-layer service calls the system's file library function, and the readdir interface will trigger the sys_getdents64 system call in the kernel. sys_getdents64 searches for the corresponding file object according to the incoming directory file descriptor (fd).
[0257] S8223. The kernel uses the Fuse user-space file system framework to call the Fuse adaptation layer to search, that is, the kernel sends a read instruction to the Fuse user-space file system framework layer.
[0258] S8224. After receiving the read instruction, the Fuse user-space file system framework layer sends the read instruction to the Fuse adaptation layer.
[0259] S8225. The Fuse adaptation layer sends a read instruction to the message transceiver module C.
[0260] The kernel calls the Fuse_readdir interface of the Fuse user-space file system framework according to the operation function specified by the found file object. The Fuse_readdir interface encapsulates the parameters into a request and sends it to the user-space libFuse through the device file / dev / Fuse. After receiving the request, libFuse calls the message transceiver module C in the distributed file system client to implement the readdir function.
[0261] After the message sending and receiving module C receives the read instruction, it instructs to read the metadata cache data from the metadata cache module. At this time, if no metadata cache data is read, that is, there is no metadata cache data in the metadata cache module, then S824 to S828 are executed; if metadata cache data is read, that is, there is metadata in the metadata cache module, then S829 is executed.
[0262] Specifically, based on S8224, when a service (such as a file management application) calls the message sending and receiving module C to implement the readdir function, the message sending and receiving module C reads metadata from the metadata cache module.
[0263] The metadata cache data indicates the metadata stored in the metadata cache module. For examples of metadata, reference can be made to the examples in S623 above, which will not be elaborated here.
[0264] S824、When no metadata cache is read, that is, there is no metadata cache in the metadata cache module, the message sending and receiving module C in the distributed file client sends a fetch instruction to the message sending and receiving module B in the distributed file server of the second electronic device. The fetch instruction is used to indicate fetching the metadata of all child nodes from the second electronic device.
[0265] Optionally, fetching metadata indicates fetching the metadata of all child nodes under the directory accessed by the user.
[0266] Among them, the fetch instruction can carry parameters, and the parameters carried can correspond to the parameters in the read instruction.
[0267] For example, the parameters carried in the fetch instruction can include: / sdcard.
[0268] For another example, the parameters carried in the fetch instruction can include: / sdcard / DCIM. " / sdcard" is the mount path corresponding to the second electronic device, and DCIM is the folder name included in the parameters of the read instruction.
[0269] S825、The message sending and receiving module B sends a fetch instruction to the local file system in the second electronic device.
[0270] It should be understood that all metadata is stored in the local file system of the second electronic device.
[0271] S826、After the local file system in the second electronic device receives the fetch instruction, it returns the corresponding metadata list to the message sending and receiving module B based on the parameters carried in the fetch instruction.
[0272] The metadata list includes one or more metadata.
[0273] It should be understood that after receiving the acquisition instruction, the message transceiver module B can call the file library function to acquire the metadata related to the instruction and return the acquired metadata to the third electronic device.
[0274] S827. The message transceiver module B sends the metadata list to the metadata cache module of the distributed file client in the third electronic device for storage.
[0275] S828. The metadata cache module sends the metadata list to the file management application.
[0276] S829. When the metadata cache data is read, that is, when there is metadata in the metadata cache module, the metadata cache module, based on the read instruction, sends the corresponding metadata list in the cache to the file management application.
[0277] Regarding S828 and S829, as Figure 8 shown, whether it is the metadata list returned from the second electronic device or the metadata list read from the metadata cache module, the metadata cache module can send the metadata list to the Fuse adaptation layer, the Fuse adaptation layer sends the metadata list to the Fuse user-space file system framework, the Fuse user-space file system framework sends the metadata list to the kernel, and the kernel then sends the metadata list to the file management application through the file library function.
[0278] Exemplarily, in response to a click operation by the user on the third electronic device on the directory P3 included in the display interface, as Figure 12 shown in (c), the third electronic device can return the metadata list read from the metadata cache module to the file management application by reading. For example, the metadata list may include the metadata corresponding to multiple subdirectories such as "Honor System", "HonorDocs", "Magazine", etc. It should be noted that this metadata list is not displayed on the display interface, that is, the user is unaware of it. Optionally, subsequently, when the file management application's file management module and the message transceiver module C send a file acquisition instruction to the message transceiver module B, the file data corresponding to the multiple subdirectories can be returned and the content shown in (d) in Figure 12 is displayed on the third electronic device.
[0279] It should be understood that when the user performs an operation to read a directory for the first time after mounting, the metadata cache module may not store any metadata. At this time, the third electronic device can execute S824 to S828 to obtain metadata from the second electronic device for the first time across devices. When the user performs an operation to read a directory for the second or Nth time, a metadata list may already be stored in the metadata cache module. Therefore, the third electronic device can execute S829, no longer perform cross-device communication, but directly read the metadata list from the local metadata cache module, thereby achieving the purpose of reducing cross-device communication and improving the reading efficiency and performance.
[0280] In addition, when there is no metadata cache in the metadata cache module, after S826, the method provided by the embodiment of the present application may further include:
[0281] S831. The message transceiver module B in the second electronic device sends a registration monitoring instruction to the file monitoring module.
[0282] This registration monitoring instruction is used to register, based on the parameters carried in the acquisition instruction, the monitoring of file changes corresponding to the directory and its subdirectories included in the parameters with the file monitoring module.
[0283] S832. After registration, the file monitoring module returns a feedback message indicating successful monitoring to the message transceiver module B.
[0284] Optionally, after S832, the method provided by the embodiment of the present application may further include:
[0285] S833. When a file in the local file system of the second electronic device changes, the local file system sends a message to the file monitoring module, and this message is used to notify the file monitoring module that a file in the local file system has changed.
[0286] S834. After receiving the message, the file monitoring module obtains new metadata from the local file system.
[0287] S835. The local file system returns the new metadata to the file monitoring module.
[0288] S836. The file monitoring module sends a file change notification to the message transceiver module B, and this file change notification may carry parameters, and the parameters may include a directory, a change event, a new file name, etc.
[0289] S837. The message transceiver module B sends the file change notification to the message transceiver module C in the third electronic device.
[0290] S838. Based on the file change notification, the message transceiver module B instructs the metadata cache module to update the metadata cache.
[0291] S839. After the metadata cache module finishes the update, it feeds back a message indicating successful update to the message transceiver module B.
[0292] S840. While executing S839, the metadata cache module can also send a notification to the kernel that the old metadata has become invalid.
[0293] Exemplarily, for instance, in response to a user's click operation, if the file management application on the third electronic device opens the photo album, the second electronic device registers to monitor the photo album directory. When the user takes a new photo using the second electronic device, the file monitoring module of the second electronic device can monitor that the file has changed. At this time, the file monitoring module can notify the message transceiver module B of this file change in real time; the message transceiver module B then notifies the message change module A of the third electronic device of the file change; after receiving the notification, the third electronic device can update the metadata in the metadata cache module based on the data carried in the notification.
[0294] Exemplarily, the parameters carried in the notification may include the directory: " / sdcard / DCIM / ", and the change event is "newly added"; the newly added file names may include: "new file name: 123.jpg" and the corresponding metadata of this name.
[0295] It should be understood that the above is an example for the newly added event. The file change event may also include: modification, deletion, etc. The change process of each event is similar to the above and can refer to the above description, which will not be elaborated here.
[0296] In the embodiment of the present application, since file monitoring is registered on the distributed file server side, when the text in the server changes, it can be notified to the distributed file client side in real time, and the cached content in the metadata cache module included in the distributed file client is updated. Thus, in the subsequent process of continuously responding to user operations to obtain the cache, the content in the metadata cache module can be kept consistent with the metadata content on the distributed file server side, avoiding data mismatch errors. Since there is also a cache in the kernel of the third electronic device, when the metadata cache module is updated, it is also necessary to notify the kernel that the original cache has become invalid, that is, the old metadata has become invalid.
[0297] In addition, each time the file on the distributed file server side changes, only the changed metadata content needs to be updated to the metadata cache module on the distributed file client side. The amount of data to be changed is small, the efficiency is high, and the energy consumption is small.
[0298] Phase Three: The Second Acquisition Phase
[0299] S841. The first electronic device displays the fourth interface and receives a user operation.
[0300] Optionally, the user operation may indicate a user operation on a local directory included in the first interface.
[0301] Exemplarily, as shown in (a) of Figure 12 , the first interface is the main interface of the file management application; in the first interface, a local directory of the first electronic device may be displayed, such as P4 in the interface shown in (c) of Figure 12 . The user operation on the local directory included in the first interface may indicate a user operation on directory P4.
[0302] For example, the user operation may indicate a click operation on the directory by the user using a mouse. Alternatively, the user operation may also be other operations such as a voice operation or an air gesture operation that indicate opening directory P4. The embodiments of the present application do not limit this.
[0303] Exemplarily, the fourth interface may be the main interface of the file management application, and the user operation may indicate a double-click operation on "My Phone: DCIM", where DCIM indicates the file directory corresponding to the photo album in the third electronic device.
[0304] S842. In response to the user operation, the file management application sends a read instruction to the file library function.
[0305] Wherein, the read instruction may carry parameters, and the parameters may include: a parent directory, such as "My Phone"; and a folder name: "DCIM".
[0306] S843. The file library function sends a read instruction to the kernel, and this read instruction is used to indicate opening a directory, or in other words, to indicate reading metadata of the directory corresponding to the user operation.
[0307] S844. The kernel returns a corresponding metadata list to the file library function.
[0308] S845. The file library function returns the metadata list to the file management application.
[0309] In the embodiments of the present application, by caching metadata in the third electronic device, when a read instruction is received, the metadata cache can be first read from the third electronic device body, reducing cross-device communication and achieving the purpose of improving the cross-device metadata reading efficiency and performance. When the metadata cache data is not read in the third electronic device, it is obtained from the second electronic device, and a file listener is registered on the second electronic device. In this way, when a file on the second electronic device changes, the metadata cache data in the third electronic device can be updated in a timely manner, with a small amount of data and high efficiency.
[0310] Optionally, the method provided in the embodiment of the present application may include: a mounting stage and a first acquisition stage.
[0311] Optionally, the method provided in the embodiment of the present application may include: a mounting phase and a second acquisition phase.
[0312] Figure 10 FIG. 2 shows a flowchart of another metadata reading method provided by an embodiment of the present application. Figure 10 As shown, the metadata reading method 900 is applied to the first electronic device 100 or the third electronic device 300 described above. The metadata reading method 900 may include the following S901 to S907, which are introduced one by one below.
[0313] S901: In response to a first operation, read metadata cache data in a first electronic device body.
[0314] Optionally, the metadata cache data is stored in a metadata cache module in the first electronic device body.
[0315] It should be understood that the first electronic device is used to Figure 6 The first electronic device 100 or Figure 8 The third electronic device 300 shown in FIG. 1 is a third electronic device 300; the metadata cache module is Figure 6 The metadata cache module in the distributed file client in the first electronic device shown, or Figure 8 The metadata cache module in the distributed file client in the third electronic device 300 is shown.
[0316] The metadata cache data is a cache object corresponding to the metadata list in the second electronic device in the first electronic device.
[0317] S902: If there is metadata cache data in the first electronic device body, read a metadata list from the first electronic device body.
[0318] In an embodiment of the present application, by caching the metadata of the second electronic device in the first electronic device body, the metadata cache data can be directly read from the first electronic device body during reading, thereby reducing cross-device communication and achieving the purpose of improving reading efficiency and performance.
[0319] S903: If there is no metadata cache data in the first electronic device body, send an acquisition instruction to the second electronic device, where the acquisition instruction is used to instruct to acquire a metadata list from the second electronic device.
[0320] S904: Receive and store the metadata list returned by the second electronic device.
[0321] It should be understood that the returned list of metadata is stored in the metadata cache module in the first electronic device.
[0322] Optionally, a B-tree structure is used to manage the metadata cache data.
[0323] For the introduction of the metadata cache data, reference can be made to the above introduction for Figure 9 what has been carried out.
[0324] Optionally, the method further includes:
[0325] S905. In response to the second operation, read the list of metadata in the first electronic device body.
[0326] S906. Read the list of metadata from the first electronic device body.
[0327] Optionally, before S901, the method further includes:
[0328] S907. The first electronic device mounts the second electronic device.
[0329] For the introduction of the mounting process, reference can be made to the above introduction for Figure 6 or Figure 8 in the mounting phase described above, which will not be elaborated here.
[0330] Optionally, after S904, the method 900 further includes:
[0331] S908. Receive a file change notification; the file change notification is used to indicate the notification returned by the second electronic device to the first electronic device when it monitors that a file in the second electronic device has changed after receiving and responding to the acquisition instruction to register a file monitor.
[0332] S909. Update the metadata cache data.
[0333] Optionally, when the file change monitored in the second electronic device is an addition, the newly added metadata is carried in the file change notification.
[0334] It should be understood that when a file in the second electronic device changes, only the changed part of the metadata can be communicated and transmitted to the first electronic device, which can not only ensure the consistency of the metadata cache data in the first electronic device and the metadata in the second electronic device, but also reduce the amount of data during communication and avoid transmitting all metadata every time when reading.
[0335] In the embodiments of the present application, by caching metadata in the first electronic device, when a read instruction is received, the metadata cache can be first read from the first electronic device body, reducing cross-device communication and achieving the purpose of improving the cross-device metadata reading efficiency and performance. When the metadata cache data is not read in the first electronic device, it is obtained from the second electronic device, and a file monitor is registered on the second electronic device. In this way, when the file on the second electronic device changes, the metadata cache data in the first electronic device can be updated in a timely manner, with a small amount of data and high efficiency.
[0336] It should be understood that although the steps in the flowcharts in the above embodiments are shown in sequence according to the arrows, these steps do not necessarily have to be executed in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps does not have a strict order limit, and these steps can be executed in other orders. Moreover, at least some of the steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages do not necessarily have to be executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages does not necessarily have to be sequential, but can be executed alternately or alternately with at least some of the other steps or sub-steps or stages of the other steps.
[0337] It can be understood that in order to implement the above functions, the electronic device includes the corresponding hardware and / or software modules for executing each function. Combining the algorithm steps of each example described in the embodiments disclosed in this article, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed in the manner of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in combination with the embodiments, but such implementation should not be considered to exceed the scope of the present application.
[0338] As described above in connection with Figures 1 to 12 , the metadata reading method, software system, and hardware system provided by the present application are described. Next, in combination with Figure 13 and Figure 14 , the chip system of the electronic device applicable to the present application will be described. It should be understood that the chip system in the embodiments of the present application can execute various methods of the foregoing embodiments of the present application, that is, the specific working processes of the following various products can refer to the corresponding processes in the foregoing method embodiments.
[0339] Figure 13 is a schematic structural diagram of an electronic device provided by an embodiment of the present application. The electronic device 1000 includes a reading module 1010 and a processing module 1020.
[0340] Among them, the reading module 1010 is configured to: in response to a first operation, read metadata cache data in the first electronic device body; the metadata cache data is a cache object corresponding to a metadata list in a second electronic device in the first electronic device; the processing module 1020 is configured to: if there is metadata cache data in the first electronic device body, read the metadata list from the first electronic device body.
[0341] It should be noted that the above electronic device 1000 is embodied in the form of functional units. The term "module" here can be implemented in software and / or hardware forms, and no specific limitation is made thereto.
[0342] For example, the "module" can be a software program, a hardware circuit, or a combination of the two that implements the above functions. The hardware circuit may include an application specific integrated circuit (ASIC), an electronic circuit, a processor (such as a shared processor, a dedicated processor, or a group of processors, etc.) for executing one or more software or firmware programs, a memory, a merged logic circuit, and / or other suitable components that support the described functions.
[0343] Therefore, the units of each example described in the embodiments of the present application can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. A person skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.
[0344] Figure 14 A schematic structural diagram of an electronic device provided by the present application is shown. Figure 14 The dashed line in indicates that the unit or the module is optional, and the electronic device 1100 can be used to implement the metadata reading method described in the above method embodiments.
[0345] The electronic device 1100 includes one or more processors 1101, and the one or more processors 1101 can support the electronic device 1100 to implement the methods in the method embodiments. The processor 1101 can be a general - purpose processor or a special - purpose processor. For example, the processor 1101 can be a central processing unit (CPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, such as discrete gate, transistor logic devices, or discrete hardware components.
[0346] The processor 1101 can be used to control the electronic device 1100, execute software programs, and process the data of software programs. The electronic device 1100 can also include a communication unit 1105 for implementing signal input (reception) and output (transmission).
[0347] For example, the electronic device 1100 can be a chip, and the communication unit 1105 can be the input and / or output circuit of the chip, or the communication unit 1105 can be the communication interface of the chip, and the chip can be a component of an electronic device or other electronic devices.
[0348] Again, for example, the electronic device 1100 can be an electronic device, and the communication unit 1105 can be the transceiver of the electronic device, or the communication unit 1105 can be the transceiver circuit of the electronic device.
[0349] The electronic device 1100 can include one or more memories 1102, on which there is a program 1104. The program 1104 can be run by the processor 1101 to generate instructions 1103, so that the processor 1101 executes the metadata reading method described in the above - mentioned method embodiments according to the instructions 1103.
[0350] Optionally, data can also be stored in the memory 1102. Optionally, the processor 1101 can also read the data stored in the memory 1102. The data can be stored at the same storage address as the program 1104, or the data can be stored at a different storage address from the program 1104.
[0351] The processor 1101 and the memory 1102 can be set separately or integrated together; for example, integrated on a system on chip (SOC) of the electronic device.
[0352] Exemplarily, the memory 1102 can be used to store the relevant program 1104 of the metadata reading method provided in the embodiments of the present application. The processor 1101 can be used to call the relevant program 1104 of the metadata reading method stored in the memory 1102 during the upgrade and execute the metadata reading method of the embodiments of the present application. For example: in response to the first operation, read the metadata cache data in the first electronic device body; the metadata cache data is the cache object corresponding to the metadata list in the second electronic device in the first electronic device; if there is metadata cache data in the first electronic device body, read the metadata list from the first electronic device body.
[0353] The present application also provides a computer program product, which implements the metadata reading method described in any method embodiment of the present application when executed by the processor 1101.
[0354] This computer program product can be stored in the memory 1102, for example, it is the program 1104. After processes such as preprocessing, compilation, assembly, and linking, the program 1104 is finally converted into an executable target file that can be executed by the processor 1101.
[0355] The present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by the computer, it implements the metadata reading method described in any method embodiment of the present application. This computer program can be a high-level language program or an executable target program.
[0356] Optionally, the computer-readable storage medium is, for example, the memory 1102. The memory 1102 may be a volatile memory or a non-volatile memory, or the memory 1102 may include both a volatile memory and a non-volatile memory. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable ROM (PROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM), and direct rambus RAM (DR RAM).
[0357] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes and the technical effects generated by the above-described devices and apparatuses can refer to the corresponding processes and technical effects in the foregoing method embodiments, and will not be elaborated herein again.
[0358] In several embodiments provided in the present application, the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, some features of the above-described method embodiments can be ignored or not executed. The above-described apparatus embodiments are merely illustrative. The division of units is only a logical function division, and there may be other division methods in actual implementation. Multiple units or components can be combined or integrated into another system. In addition, the coupling between units or the coupling between components can be direct coupling or indirect coupling. The above couplings include electrical, mechanical, or other forms of connection.
[0359] It should be understood that in various embodiments of the present application, the magnitude of the serial numbers of the various processes does not imply the order of execution, and the order of execution of the various processes should be determined by their functions and internal logics, and should not constitute any limitation on the implementation process of the embodiments of the present application.
[0360] In addition, the terms "system" and "network" are often used interchangeably herein. The term "and / or" in this article is merely a description of the association relationship between associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this article generally represents an "or" relationship between the associated objects before and after.
[0361] In summary, the above description is only a preferred embodiment of the technical solution of the present application, and is not used to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.
Claims
1. A method for reading metadata, characterized in that, Applied to a first electronic device, the method includes: In response to a first operation, read metadata cache data in the first electronic device body; the metadata cache data is a cache object corresponding to a metadata list in a second electronic device in the first electronic device; If there is the metadata cache data in the first electronic device body, read the metadata list from the first electronic device body.
2. The metadata reading method according to claim 1, wherein The method further includes: If there is no such metadata cache data in the first electronic device body, send a fetch instruction to the second electronic device, where the fetch instruction is used to indicate fetching the metadata list from the second electronic device; Receive the metadata list returned by the second electronic device and store it.
3. The metadata reading method according to claim 2, wherein The method further includes: Receive a file change notification; the file change notification is used to indicate a notification returned by the second electronic device to the first electronic device after the second electronic device receives and responds to the fetch instruction to register a file monitor and then monitors that a file in the second electronic device has changed; Update the metadata cache data.
4. The metadata reading method according to claim 3, wherein When the file change monitored in the second electronic device is an addition, the new metadata is carried in the file change notification.
5. The metadata reading method according to any one of claims 1 to 4, characterized in that The metadata cache data is stored in a metadata cache module in the first electronic device body.
6. The metadata reading method according to claim 5, wherein Use a B-tree structure to manage the metadata cache data.
7. The metadata reading method according to any one of claims 3 to 6, characterized in that, When the software system of the first electronic device is an Android architecture, the method further includes: after updating the metadata cache data, notify the kernel that the old metadata cache data becomes invalid.
8. The metadata reading method according to any one of claims 1 to 7, characterized in that The method further includes: Run a file management application; In response to the second electronic device going online, mount the second electronic device.
9. The metadata reading method according to claim 8, characterized in that, The first operation is an open operation on a directory in the file management application.
10. An electronic device, characterized in that, Includes a processor and a memory; The memory is used to store a computer program that can run on the processor; The processor is used to execute the metadata reading method according to any one of claims 1 to 9.
11. A chip system, characterized in that, Includes: a processor, used to call and run a computer program from a memory, so that a device installed with the chip executes the metadata reading method according to any one of claims 1 to 9.
12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program includes program instructions, and when the program instructions are executed by a processor, the processor is caused to execute the metadata reading method according to any one of claims 1 to 9.
Citation Information
Patent Citations
Metadata management method and electronic equipment
CN114328377A
Content management method, electronic equipment and system
CN116561459A