Equipment mounting method, electronic equipment and computer readable storage medium

Abstract

The invention discloses an equipment mounting method, electronic equipment and a computer readable storage medium, and belongs to the technical field of mounting. The method comprises the following steps: mounting a local file system; and generating a mounted directory tree according to the target mounted directory, wherein a root directory of the mounted directory tree is the target mounted directory. And acquiring mounting request information, wherein the mounting request information comprises the second equipment identifier, a local access directory and a target equipment directory. And creating at least one node in a mounted directory tree according to the mounting request information, wherein the tail of a mounted directory indicated by a leaf node in the at least one node is a second device identifier and a target device directory. And associating the local access catalog with the mounting catalog indicated by the leaf node, so that the associated mounting between the local access catalog and the target device catalog in the second device is realized, and the first device can access the file in the target device catalog in the second device through the local access catalog.

Description

Technical Field

[0001] The present application relates to the field of mounting technology, and in particular to a device mounting method, an electronic device and a computer-readable storage medium. Background Art

[0002] At present, people often save a lot of files in their daily work and life. For example, office workers, scientific researchers, college students and other groups need to save a lot of office summaries, scientific research reports, learning materials and other files. These files are often distributed in different devices such as mobile phones, tablets, and laptops. When using these files, users often need to browse files across devices, search files across devices, or transfer files across devices. Summary of the invention

[0003] The present application provides a device mounting method, an electronic device and a computer-readable storage medium, which can access files in a target device directory in a second device through a local access directory. The technical solution is as follows:

[0004] In the first aspect, a device mounting method is provided. In the method, a first device mounts a local file system, and the directory of the local file system is a target mounting directory. A mounting directory tree is generated according to the target mounting directory, and the root directory of the mounting directory tree is the target mounting directory. Afterwards, a mounting request message is obtained, and the mounting request message carries mounting parameters, and the mounting parameters include a second device identifier, a local access directory, and a target device directory. The local access directory is a directory accessed when a file is accessed locally, and the target device directory is a directory in a second device identified by the second device identifier. At least one node is created in the mounting directory tree according to the mounting request message, and the end of the mounting directory indicated by the leaf node in the at least one node is the second device identifier and the target device directory. The local access directory is associated with the mounting directory indicated by the leaf node.

[0005] In the present application, the association mounting between the local access directory in the first device and the target device directory in the second device can be realized, so that the first device can access the files in the target device directory in the second device through the local access directory, which is convenient for users.

[0006] Optionally, before creating at least one node in the mount directory tree according to the mount request information, the mount parameter may be verified for legitimacy; if the mount parameter passes the verification for legitimacy, then if the application that generates the mount request information has mount permission and the local access directory exists, the operation of creating at least one node in the mount directory tree according to the mount request information is executed. In this way, the mount success rate can be improved.

[0007] Optionally, before creating at least one node in the mount directory tree according to the mount request information, a mount negotiation may be performed with the second device, and if the mount negotiation is successful, an operation of creating at least one node in the mount directory tree according to the mount request information is performed. In this way, the mount success rate can be improved.

[0008] Among them, when the second device is not currently mounted, the mount negotiation content with the second device includes: whether the second device supports distributed file capabilities, whether the target device directory exists in the second device, and whether the distributed file switch of the second device is turned on; when the second device is currently mounted, the mount negotiation content with the second device includes: whether the target device directory exists in the second device, and whether the distributed file switch of the second device is turned on.

[0009] Optionally, before creating at least one node in the mount directory tree according to the mount request information, the following operations may also be performed: if the first node does not exist in the mount directory tree, execute the step of creating at least one node in the mount directory tree according to the mount request information, the data of the first node is the root directory of the target device directory, and the data of the parent node of the first node is the second device identifier, and the at least one node includes the first node; create mount information for the first node in the mount directory tree, the mount information includes a reference count, a device identifier and an application identifier, the reference count is 1, the device identifier is the second device identifier, and the application identifier is the identifier of the application that generates the mount request information.

[0010] If the first node does not exist in the mount directory tree, it means that the target device directory in the second device is mounted for the first time, so the at least one node can be created in the mount directory tree to achieve the mounting of the target device directory in the second device. In addition, the reference count in the mount information of the first node in the mount directory tree can be set to 1.

[0011] Optionally, before creating at least one node in the mount directory tree according to the mount request information, the following operation may also be performed: if there is a first node in the mount directory tree, the reference count in the mount information of the first node is increased by 1, and the identifier of the application that generated the mount request information is added to the application identifier in the mount information of the first node, and the step of creating at least one node in the mount directory tree according to the mount request information is executed, the data of the first node is the root directory of the target device directory, and the data of the parent node of the first node is the second device identifier.

[0012] If the first node exists in the mount directory tree, it means that the root directory in the target device directory in the second device has been mounted. Therefore, the reference count in the mount information of the first node can be increased by 1, and then at least one node can be created in the mount directory tree to realize the mounting of the target device directory in the second device.

[0013] Optionally, the method further includes: obtaining an uninstallation request message, the uninstallation request message carrying the file access directory; and uninstalling the mount directory associated with the file access directory.

[0014] Optionally, the operation of unloading the mount directory associated with the file access directory can be: determining the mount directory associated with the file access directory as the second directory; reducing the reference count in the mount information of the third node by 1, and the third node is the node that has the mount information among all the nodes constituting the second target in the mount directory tree; if the reference count in the mount information of the third node is not 0 after being reduced by 1, then canceling the association between the third node in the mount directory tree and the mount directory indicated by the node under the third node and the file access directory corresponding to the application that generated the uninstall request message.

[0015] Optionally, after deducting the reference count in the mount information of the third node by 1, if the reference count in the mount information of the third node is 0 after deducting 1, the parent node of the third node, the third node and all nodes under the third node in the mount directory tree are deleted, and the association between the mount directory indicated by the deleted node and the file access directory is cancelled, and an uninstall message is sent to the device identified by the data of the parent node of the third node.

[0016] In the present application, it can be determined whether the directory to be uninstalled has been mounted. If it has been mounted, the reference count of the uninstall directory is reduced by 1. If the reference count is not 0, a non-real uninstall is performed. If the reference count is 0, a real uninstall is performed. Then the uninstall result is returned. Among them, the operation of non-real uninstallation can be: deleting related nodes and canceling the association between the local access directory and the uninstall directory. The operation of real uninstallation can be: deleting related nodes, instructing the server to uninstall, then clearing the local data cache, and then canceling the association between the local access directory and the uninstall directory.

[0017] In a second aspect, a device mounting apparatus is provided, the device mounting apparatus has the function of implementing the device mounting method behavior in the first aspect. The device mounting apparatus includes at least one module, and the at least one module is used to implement the device mounting method provided in the first aspect.

[0018] In a third aspect, an electronic device is provided, wherein the structure of the electronic device includes a processor and a memory, wherein the memory is used to store a program that supports the electronic device to execute the device mounting method provided in the first aspect, and to store data involved in implementing the device mounting method described in the first aspect. The processor is configured to execute the program stored in the memory. The electronic device may also include a communication bus, wherein the communication bus is used to establish a connection between the processor and the memory.

[0019] In a fourth aspect, a computer-readable storage medium is provided, wherein instructions are stored in the computer-readable storage medium, and when the computer-readable storage medium is run on a computer, the computer executes the device mounting method described in the first aspect.

[0020] In a fifth aspect, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to execute the device mounting method described in the first aspect.

[0021] The technical effects obtained by the above-mentioned second, third, fourth and fifth aspects are similar to the technical effects obtained by the corresponding technical means in the above-mentioned first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 It is a structural schematic diagram of an electronic device provided in an embodiment of the present application;

[0023] Figure 2 is a block diagram of a software system of an electronic device provided in an embodiment of the present application;

[0024] Figure 3 is a schematic diagram of a distributed system provided in an embodiment of the present application;

[0025] Figure 4 It is a schematic diagram of a mounted directory tree provided in an embodiment of the present application;

[0026] Figure 5 is a flow chart of a device mounting method provided in an embodiment of the present application;

[0027] Figure 6 is a block diagram of a software system of a first device and a second device provided in an embodiment of the present application;

[0028] Figure 7 is a schematic diagram of a basic interface for obtaining vold service provided in an embodiment of the present application;

[0029] Figure 8 This is a schematic diagram of a Fuse framework provided in an embodiment of the present application to complete the mounting of a local file system;

[0030] Fig. 9 It is a schematic diagram of the structure of a mount directory tree and the usage position in the mount process provided by an embodiment of the present application;

[0031] Fig.10 is a schematic diagram of a mounting step provided in an embodiment of the present application;

[0032] Fig.11 It is a schematic diagram of an uninstallation step provided in an embodiment of the present application. DETAILED DESCRIPTION

[0033] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below in conjunction with the accompanying drawings.

[0034] It should be understood that the "multiple" mentioned in this application refers to two or more. In the description of this application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in order to facilitate the clear description of the technical solution of this application, the words "first" and "second" are used to distinguish between the same items or similar items with basically the same functions and effects. Those skilled in the art can understand that the words "first" and "second" do not limit the quantity and execution order, and the words "first" and "second" do not limit them to be different.

[0035] The phrases such as "one embodiment" or "some embodiments" described in the present application mean that the specific features, structures or characteristics described in the embodiment are included in one or more embodiments of the present application. Therefore, the phrases such as "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments" that appear in the differences in the present application do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. In addition, the terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0036] The electronic device involved in the embodiments of the present application is described below.

[0037] Figure 1 1 is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of the present application. Figure 1The electronic device 100 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, an earphone interface 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, an air 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.

[0038] It is to be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0039] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0040] The controller may be the nerve center and command center of the electronic device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0041] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0042] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function, such as storing music, video and other files in the external memory card.

[0043] The internal memory 121 can be used to store computer executable program codes, which include instructions. The processor 110 executes various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 121. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created by the electronic device 100 during use (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0044] The USB interface 130 is an interface that complies with the USB standard specification, and specifically can be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 130 can be used to connect a charger to charge the electronic device 100, and can also be used to transfer data between the electronic device 100 and a peripheral device. It can also be used to connect headphones to play audio through the headphones. The USB interface 130 can also be used to connect other devices, such as AR devices, etc.

[0045] The charging management module 140 is used to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger through the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive wireless charging input through a wireless charging coil of the electronic device 100. While the charging management module 140 is charging the battery 142, it may also power the electronic device 100 through the power management module 141.

[0046] The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, and provides power to the processor 110, the internal memory 121, the external memory, the display screen 194, the camera 193 and the wireless communication module 160. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle number, battery health status (leakage, impedance), etc. In some other embodiments, the power management module 141 can also be set in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 can also be set in the same device.

[0047] The wireless communication function of the electronic device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

[0048] 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 reused to improve the utilization of the antennas. For example, antenna 1 can be reused 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.

[0049] The mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, and filter, amplify, and process the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the same device as at least some of the modules of the processor 110.

[0050] The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to the electronic device 100. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the frequency of the electromagnetic wave signal and performs filtering, and sends the processed signal to the processor 110. The wireless communication module 160 can also receive the signal to be sent from the processor 110, modulate the frequency of it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

[0051] The electronic device 100 implements the display function through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, which connects 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 that execute program instructions to generate or change display information.

[0052] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light emitting diode or an active-matrix organic light emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device 100 may include 1 or N display screens 194, where N is an integer greater than 1.

[0053] The electronic device 100 can realize the shooting function through ISP, camera 193, video codec, GPU, display screen 194 and application processor.

[0054] ISP is used to process the data fed back by camera 193. For example, when taking a photo, the shutter is opened, and the light is transmitted to the camera photosensitive element through the lens. The light signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to ISP for processing and converts it into an image visible to the naked eye. ISP can also perform algorithm optimization on the noise, brightness, and skin color of the image. ISP can also optimize the exposure, color temperature and other parameters of the shooting scene. In some embodiments, ISP can be set in camera 193.

[0055] The camera 193 is used to capture still images or videos. The object generates an optical image through the lens and projects it onto the photosensitive element. The photosensitive element can be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, and then passes the electrical signal to the ISP to be converted 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 a standard RGB, YUV or other format. In some embodiments, the electronic device 100 may include 1 or N cameras 193, where N is an integer greater than 1.

[0056] The electronic device 100 can implement audio functions, such as music playback, recording, etc., through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone interface 170D and the application processor.

[0057] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The audio module 170 can also be used to encode and decode audio signals. In some embodiments, the audio module 170 can be arranged in the processor 110, or some functional modules of the audio module 170 can be arranged in the processor 110.

[0058] The key 190 includes a power key, a volume key, etc. The key 190 may be a mechanical key or a touch key. The electronic device 100 may receive key inputs and generate key signal inputs related to user settings and function control of the electronic device 100.

[0059] Motor 191 can generate vibration prompts. Motor 191 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback. For example, touch operations acting on different applications (such as taking pictures, audio playback, etc.) can correspond to different vibration feedback effects. Touch operations acting on different areas of the display screen 194 can also correspond to different vibration feedback effects. Different application scenarios (such as: time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also support customization.

[0060] Indicator 192 may be an indicator light, which may be used to indicate charging status, power changes, messages, missed calls, notifications, etc.

[0061] The SIM card interface 195 is used to connect a SIM card. The SIM card can be connected to and separated from the electronic device 100 by inserting it into the SIM card interface 195 or pulling it out from the SIM card interface 195. The electronic device 100 can support 1 or N SIM card interfaces, where N is an integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, and the like. Multiple cards can be inserted into the same SIM card interface 195 at the same time. The types of the multiple cards can be the same or different. The SIM card interface 195 can also be compatible with different types of SIM cards. The SIM card interface 195 can also be compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to implement functions such as calls and data communications. In some embodiments, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

[0062] Next, the software system of the electronic device 100 will be described.

[0063] The software system of the electronic device 100 may adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present application takes the Android system of the layered architecture as an example to exemplify the software system of the electronic device 100.

[0064] Figure 2 1 is a block diagram of a software system of an electronic device 100 provided in an embodiment of the present application. Figure 2 The layered architecture divides the software into several layers, each with clear roles and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into an application layer, an application framework layer, an Android runtime (AndroidRuntime) and a system layer, and a kernel layer.

[0065] The application layer can include a series of application packages. Figure 2 As shown, the application package may include camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message and other applications.

[0066] The application framework layer provides application programming interface (API) and programming framework for the applications in the application layer. The application framework layer includes some predefined functions. Figure 2As shown, the application framework layer may include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, etc. The window manager is used to manage window programs. The window manager can obtain the size of the display screen, determine whether there is a status bar, lock the screen, capture the screen, etc. The content provider is used to store and obtain data and make these data accessible to applications. These data may include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc. The view system includes visual controls, such as controls for displaying text, controls for displaying pictures, etc. The view system can be used to build the display interface of the application, and the display interface can be composed of one or more views, for example, including a view for displaying a text message notification icon, including a view for displaying text, and including a view for displaying pictures. The phone manager is used to provide communication functions of the electronic device 100, such as management of call status (including connecting, hanging up, etc.). The resource manager provides various resources for the application, such as localized strings, icons, pictures, layout files, video files, etc. The notification manager enables the application to display notification information in the status bar, which can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of an icon or scroll bar text, such as a notification of an application running in the background. The notification manager can also be a notification that appears on the screen in the form of a dialog window, such as a text message in the status bar, a reminder sound, an electronic device vibrating, an indicator light flashing, etc.

[0067] Android Runtime includes core libraries and virtual machines. Android Runtime is responsible for scheduling and management of the Android system. The core library consists of two parts: one is the function that the Java language needs to call, and the other is the Android core library. The application layer and the application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0068] The system layer can include multiple functional modules, such as: surface manager, media library, 3D graphics processing library (such as: OpenGL ES), 2D graphics engine (such as: SGL), etc. The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications. The media library supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc. The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, synthesis, and layer processing, etc. The 2D graphics engine is a drawing engine for 2D drawing.

[0069] The kernel layer is the layer between hardware and software. The kernel layer can include display drivers, camera drivers, audio drivers, sensor drivers, etc.

[0070] The application scenarios involved in the embodiments of the present application are described below.

[0071] At present, people often save a lot of files in their daily work and life. For example, office workers, scientific researchers, college students and other groups need to save a lot of office summaries, scientific research reports, learning materials and other files. These files are often distributed in different devices such as mobile phones, personal digital assistants (PDAs), and personal computers (PCs). When using these files, users often need to browse files across devices, search for files across devices, or transfer files across devices.

[0072] To this end, an embodiment of the present application provides a distributed system. The distributed system includes multiple devices, and any two of the multiple devices have the ability to mount access each other, so that any two of the multiple devices can browse, search and transfer files across devices.

[0073] Next, the distributed system provided in the embodiment of the present application is described.

[0074] Figure 3 Schematic diagram of a distributed system provided by an embodiment of the present application. Figure 3 , the distributed system includes multiple devices 300.

[0075] Any one of the plurality of devices 300 may be the above Figure 1 to Figure 2 The electronic device 100 described in the embodiment, for example, any one of the multiple devices 300 can be a mobile phone, a PDA, a PC, etc., which is not limited in the embodiment of the present application.

[0076] Any device 300 (which may be referred to as a second device) among the multiple devices 300 may be mounted to another device 300 (which may be referred to as a first device). In this case, the first device may be used as a client, and the second device may be used as a server. The server is mounted to the client, and the client may access files in the server.

[0077] There may be multiple clients or multiple servers among the multiple devices 300. Moreover, any one of the multiple devices 300 may be a client or a server. In other words, any one of the multiple devices 300 may be mounted with other devices 300 or may be mounted to other devices 300.

[0078] Optionally, any one of the multiple devices 300 may have multiple applications (also referred to as business applications). Multiple applications in this device 300 may apply to mount other devices 300 on this device 300, and the other devices 300 that the multiple applications apply to mount may be the same device or different devices. The multiple applications may access files in the devices 300 on which they are mounted. For example, the multiple applications may include a file manager, a workstation, a gallery, etc., which is not limited solely to this embodiment of the present application.

[0079] The following is an explanation of the mounting directory tree involved in the embodiment of the present application.

[0080] The mount directory tree can also be called the mount manager tree (MMT).

[0081] Figure 4 Schematic diagram of a mounted directory tree provided in an embodiment of the present application. Figure 4 As shown, the mount directory tree is a tree structure. The data of each node in the mount directory tree is a directory. The data of the root node of the mount directory tree can be called a root directory, and the data of other nodes in the mount directory tree except the root node can be called a subdirectory.

[0082] for example, Figure 4 The data of the root node of the mounted directory tree shown is the root directory " / mnt / appfuse / dfs", the data of each node in the next layer of nodes of the root node are sub-directories " / " and " / default", the data of each node in the next layer of nodes are " / device1" and " / device2", the data of each node in the next layer of nodes are " / sdcard", and the data of each node in the next layer of nodes is " / memory".

[0083] Each node in the mount directory tree indicates a mount directory, that is, indicates a mount point. For example, the mount directory indicated by each node in the mount directory tree can be a disk directory.

[0084] The mount directory indicated by the root node of the mount directory tree is the root directory of the mount directory tree, that is, the directory of the local file system, that is, the mount point of the local file system. Other nodes in the mount directory tree except the root node indicate the mount directories of other devices, that is, the mount points of other devices. The mount directory indicated by any other node in the mount directory tree except the root node is a directory composed of the data of all nodes in the path from the root node to this node.

[0085] for example, Figure 4 The mount directory indicated by the root node of the mount directory tree shown is " / mnt / appfuse / dfs", and the mount directories indicated by each node in the next layer of nodes of the mount directory tree are " / mnt / appfuse / dfs / " and " / mnt / appfuse / dfs / default", and the mount directories indicated by each node in the next layer of nodes are " / mnt / appfuse / dfs / default / device1" and " / mnt / appfuse / dfs / default / device2", and the mount directories indicated by each node in the next layer of nodes are " / mnt / appfuse / dfs / default / device1 / sdcard" and " / mnt / appfuse / dfs / default / device2 / sdcard", and the mount directory indicated by each node in the next layer of nodes is " / mnt / appfuse / dfs / default / device2 / sdcard / memory".

[0086] Among them, the mount directory tree contains the mount directory of the target device directory which mounts other devices, and the target device directory is the directory in the other device. For example, Figure 4In the mount directory tree shown, the end of the mount directories " / mnt / appfuse / dfs / default / device1 / sdcard" and " / mnt / appfuse / dfs / default / device2 / sdcard" is the target device directory " / sdcard", and the end of the mount directory " / mnt / appfuse / dfs / default / device2 / sdcard / memory" is the target device directory " / sdcard / memory". The root directory in the target device directory " / sdcard" is " / sdcard", and the root directory in the target device directory " / sdcard / memory" is " / sdcard".

[0087] In some embodiments, if the data of a node in the mount directory tree is the root directory in the target device directory, then mount information (also referred to as MountInfo) may be set for this node. Figure 4 As shown, you can set the mount information for the node where the root directory " / sdcard" in the target device directory is located.

[0088] The mount information of a node may include a reference count, a device identifier (also called a device ID (Identity document)), an application identifier, and may further include read and write permissions, etc.

[0089] The reference count is the number of times the mount directory indicated by this node is mounted by the application. The device identifier is the identifier of the other device corresponding to the mount directory indicated by this node. The application identifier is the identifier of the application that mounts the mount directory indicated by this node, such as the package name of the application. The read and write permissions refer to the read and write permissions of the files in the mount directory indicated by this node, which can include read-only, write-only, and read-write.

[0090] The device mounting method involved in the embodiment of the present application is described below.

[0091] Figure 5 is a flow chart of a device mounting method provided by an embodiment of the present application. Figure 5 , the method comprises the following steps:

[0092] Step 501: The first device mounts the local file system.

[0093] The local file system is a file system used in the first device to mount other devices. After the first device mounts the local file system, it can use the local file system to mount other devices. For example, the local file system can be a disk file system, etc., and the embodiments of the present application do not limit this to a single one.

[0094] The first device may mount the local file system according to the target mount directory. The target mount directory is a directory of the local file system. Moreover, the target mount directory is the mount point of the local file system on the first device, and is also the mount point of other devices subsequently mounted on the first device. For example, the target mount directory may be pre-set, such as / mnt / appfuse / dfs.

[0095] Step 502: The first device generates a mount directory tree according to the target mount directory.

[0096] For example, the mount directory tree may be set in the memory of the first device.

[0097] The data of the root node of the mount directory tree is the target mount directory. The mount directory indicated by the root node is the target mount directory, that is, the mount point of the local file system. Other nodes in the mount directory tree except the root node indicate the mount directories of other devices, that is, the mount points of other devices. The mount directory indicated by any node in the mount directory tree except the root node is a directory composed of the data of all nodes in the path from the root node to this node.

[0098] After the first device generates the mount directory tree, other devices can be mounted according to the mounting requirements of the application.

[0099] Step 503: The first device obtains mounting request information.

[0100] Optionally, the mount request information may be generated by an application having a mount requirement in the first device.

[0101] For example, the mount request information may carry mount parameters. The mount parameters may include a second device identifier, a local access directory (also referred to as a service access directory), a target device directory, and may further carry a file system type, etc. Optionally, the mount parameters may also carry a callback function for receiving a mount result.

[0102] The mount request information is used to request to associate and mount the local access directory in the mount request information with the target device directory in the second device identified by the second device identifier in the mount request information.

[0103] Among them, the second device identifier is the identifier of the second device to be mounted by the mount request information. The local access directory is the directory accessed when accessing files locally, that is, the directory accessed by the application that generates the mount request information when accessing files. The target device directory is the directory in the second device to be mounted by the mount request information. The file system type is the type of the local file system. In this case, after the mount is successfully performed according to the mount request information, the application in the first device can access the files in the target device directory in the second device by accessing the local access directory.

[0104] As an example, the local access directories mounted by various applications in the first device may be different. In this case, before generating the mount request information, the application may first query whether the local access directory to be mounted has been mounted. If the local access directory is not mounted, the application may generate a mount request information. If the local access directory has been mounted, the application cannot mount the local access directory again. At this time, the application may choose not to generate a mount request information, or the application may try to change other local access directories and generate a mount request information again if the changed local access directory is not mounted.

[0105] In some cases, after the first device obtains the mount request information, it can verify the legitimacy of the mount parameters in the mount request information. For example, the first device can verify whether the length of the second device identifier in the mount request information is legal, and verify whether the formats of the local access directory and the target device directory in the mount request information are legal.

[0106] If the legitimacy check of the mount parameters in the mount request information fails, the first device does not continue to perform the following step 504, but directly determines that the mount result is a mount failure, and sends the mount result to the application that generated the mount request information, for example, the mount result can be sent to the application according to the callback function in the mount request information. The mount result can also carry an error code, which is used to indicate the reason for the mount failure.

[0107] If the legitimacy check of the mount parameters in the mount request information passes, the first device can also determine whether the application that generates the mount request information has mount permission, and determine whether the local access directory in the mount request information exists. For example, the first device can parse the local configuration file and determine whether the application has mount permission based on the local configuration file. If the application has mount permission and the local access directory exists, the first device can continue to execute the following step 504; otherwise, the first device does not continue to execute the following step 504, but directly determines that the mount result is a mount failure, and sends the mount result to the application.

[0108] In this case, the first device performs the mount operation only when the mount parameters in the mount request information are legal, the application has the mount permission, and the local access directory exists, thereby improving the mount success rate.

[0109] In some cases, the first device may also perform a mount negotiation with the second device before executing step 504. If the mount negotiation with the second device is successful, the first device continues to perform step 504, thereby improving the mount success rate. If the mount negotiation with the second device fails, the first device does not continue to perform step 504, but directly determines that the mount result is a mount failure, and sends the mount result to the application.

[0110] If the second device is not currently mounted, the mount negotiation content between the first device and the second device includes: whether the second device supports distributed file capabilities, whether the target device directory exists in the second device, and whether the distributed file switch in the second device is turned on. If the second device supports distributed file capabilities, the target device directory exists in the second device, and the distributed file switch in the second device is turned on, it is determined that the mount negotiation between the first device and the second device is successful; otherwise, it is determined that the mount negotiation between the first device and the second device has failed.

[0111] If the second device is currently mounted, the mount negotiation content between the first device and the second device includes: whether the target device directory exists in the second device, and whether the distributed file switch in the second device is turned on. If the target device directory exists in the second device, and the distributed file switch in the second device is turned on, it is determined that the mount negotiation between the first device and the second device is successful; otherwise, it is determined that the mount negotiation between the first device and the second device has failed.

[0112] The distributed file capability is used to indicate that the electronic device supports the device mounting solution provided in the embodiment of the present application. If the second device supports the distributed file capability, the second device is Figure 3 In the distributed system shown is an electronic device 300, the second device supports being mounted to other electronic devices in the distributed system.

[0113] The distributed file switch is used to indicate whether the electronic device allows the device mounting solution provided in the embodiment of the present application to be implemented. If the distributed file switch in the second device is turned on, it means that the second device currently allows itself to be mounted on other devices. If the distributed file switch in the second device is turned off, it means that the second device currently does not allow itself to be mounted on other devices.

[0114] Step 504: The first device creates at least one node in the mount directory tree according to the mount request information.

[0115] The order from the first node to the last node in the at least one node is the order from the uppermost node to the lowermost node in the at least one node. In this case, the end of the mount directory indicated by the last node (i.e., the leaf node) in the at least one node is the first directory, and the end of the first directory is the target device directory. The first directory may also include a target subdirectory, and the target subdirectory is the second device identifier, and the target subdirectory is the parent directory of the target device directory. For example, the first directory may also include a specified subdirectory, and the specified subdirectory is the parent directory of the target subdirectory. The specified subdirectory may be pre-set, for example, the specified subdirectory may be pre-set group information, and the group information may be default. The group information is used to indicate the group to which the device indicated by the target subdirectory belongs.

[0116] Step 505: The first device associates the local access directory with the mount directory indicated by the leaf node in the at least one node.

[0117] After creating the at least one node in the mount directory tree, the target device directory in the second device can be mounted. In addition, the local access directory is associated with the mount directory indicated by the leaf node in the at least one node. In this way, the associated mounting of the local access directory and the target device directory in the second device is achieved. In this case, when an application accesses the local access directory, the first device can obtain the mount directory associated with the local access directory according to the mount directory tree, and then access the files in the target device directory in the second device according to the mount directory.

[0118] In some embodiments, after executing step 503, the first device may first determine whether the mount directory tree contains a mount directory ending with the first directory.

[0119] If the mount directory tree contains a mount directory ending with the first directory, it means that the target device directory in the second device has been mounted before, and the first device may not perform steps 504 and 505, but add 1 to the reference count in the mount information of the first node, and add the identifier of the application that generates the mount request information to the application identifier in the mount information of the first node, and associate the file access directory with the mount directory ending with the first directory in the mount directory tree. The data of the first node is the root directory of the target device directory, and the data of the parent node of the first node is the second device identifier.

[0120] If the mount directory tree does not contain a mount directory ending with the first directory, it means that the target device directory in the second device has not been mounted before. The first device can execute steps 504 and 505 to mount the target device directory in the second device, and then associate the local access directory with the mount directory in the mount directory tree ending with the first directory (that is, the mount directory indicated by the leaf node in the at least one node mentioned above).

[0121] Furthermore, in the case where the mount directory tree does not contain a mount directory ending with the first directory, before executing steps 504 and 505, the first device may determine whether the first node exists in the mount directory tree. If the first node exists in the mount directory tree, the first device may add 1 to the reference count in the mount information of the first node, and add the identifier of the application that generates the mount request information to the application identifier in the mount information of the first node, and then execute steps 504 and 505. If the first node does not exist in the mount directory tree, the first device may execute steps 504 and 505. In this case, the at least one node includes the first node, and mount information is created for the first node in the mount directory tree, the reference count in the mount information is 1, the device identifier in the mount information is the second device identifier in the mount request information, the application identifier in the mount information is the identifier of the application that generates the mount request information, and the read and write permissions in the mount information are the read and write permissions of the target device directory in the second device.

[0122] Further, after performing the above operation, the first device may send an initialization message to the second device, and the initialization message may carry the target device directory. After receiving the initialization message, the second device may initialize its own mounting service, obtain metadata of the root directory in the target device directory, and then send the metadata to the first device. After receiving the metadata, the first device may store the metadata.

[0123] After the first device successfully realizes the association mounting between the file access directory and the target device directory in the second device, it can determine that the mounting result is successful. The first device can send the mounting result to the application that generates the mounting request information, for example, the mounting result can be sent to the application according to the callback function in the mounting request information.

[0124] Optionally, the embodiment of the present application may provide a single directory mount, or may provide multiple directory mounts (i.e., batch directory mounts). For batch directory mounts, it may be an atomic batch directory mount, that is, when one directory mount fails, all directory mounts fail; or it may be a non-atomic batch mount, that is, when one directory mount fails, it does not affect the mounting of other directories.

[0125] Specifically, the application may generate a mount instruction including a mount request information. After the first device obtains the mount instruction, it may perform the mount operation according to the above steps 503 to 505 for the mount request information in the mount instruction.

[0126] Alternatively, the application may generate a mount instruction including multiple mount request information. After the first device obtains the mount instruction, for each mount request information in the mount instruction, the mount operation may be performed according to the above steps 503 to 505. In this case, if it is an atomic batch directory mount, then if at least one mount request information in the multiple mount request information in the mount instruction has a mount failure result, it can be determined that the mount results of all the mount request information in the mount instruction are mount failures. If it is a non-atomic batch directory mount, the mount results of each mount request information in the mount instruction will not affect each other.

[0127] It should be noted that after the application associates and mounts the file access directory and the target device directory in the second device, if the application wants to access the file in the target device directory in the second device, the application can generate a file access request carrying the file access directory. After the first device obtains the file access request, it can obtain the mount directory associated with the file access directory from the mount directory tree, and then access the file in the target device directory in the second device based on the mount directory. The access here can be file reading and writing.

[0128] In some embodiments, the first device can not only mount directories in other devices, but also unmount directories in other mounted devices.

[0129] In the first case, the first device may unmount all directories in the third device when the third device is disconnected from the first device.

[0130] The third device is a device other than the first device. Optionally, when the first device is offline or the third device is offline, the first device and the third device are disconnected.

[0131] The operation of the first device uninstalling all directories in the third device may be: the first device deletes the node where the third device identifier is located in the mount directory tree and all nodes under the node, and cancels the association between the mount directories indicated by the deleted nodes and the file access directories.

[0132] In the second case, the first device may uninstall the directory mounted by the application when the application is uninstalled, or the first device may uninstall the directory mounted by the application when the application crashes or exits without accessing the file.

[0133] The operation of the first device uninstalling the directory mounted by the application can be: the first device reduces the reference count in the mount information of the second node in the mount directory tree by 1, and the second node is the node in which the identifier of the application exists in the application identifier in the mount information. If the reference count in the mount information of the second node is reduced by 1 to 0, the parent node, the second node and all nodes under the second node of the second node in the mount directory tree are deleted, and the association between the mount directory indicated by these deleted nodes and the file access directory is cancelled, and an uninstall message is sent to the device identified by the data of the parent node of the second node, and the device can stop the relevant service after receiving the uninstall message. If the reference count in the mount information of the second node is not 0 after being reduced by 1, the association between the mount directory indicated by the second node and all nodes under the second node and the file access directory corresponding to the application is cancelled.

[0134] In the third case, the first device may obtain uninstallation request information generated by the application, where the uninstallation request message carries a file access directory, and the first device uninstalls the mount directory associated with the file access directory.

[0135] The operation of the first device to unload the mount directory associated with the file access directory may be as follows: the first device determines the mount directory associated with the file access directory as the second directory, and reduces the reference count in the mount information of the third node by 1, where the third node is a node in the mount directory tree that has mount information among all the nodes that constitute the second directory; if the reference count in the mount information of the third node is reduced by 1 to 0, the parent node of the third node, the third node, and all nodes under the third node in the mount directory tree are deleted, and the association between the mount directory indicated by these deleted nodes and the file access directory is cancelled, and an unloading message is sent to the device identified by the data of the parent node of the third node, and the device can stop the relevant service after receiving the unloading message; if the reference count in the mount information of the third node is not 0 after being reduced by 1, the association between the mount directory indicated by the third node and all nodes under the third node and the file access directory corresponding to the application is cancelled.

[0136] In an embodiment of the present application, the first device mounts a local file system, and the directory of the local file system is the target mount directory. A mount directory tree is generated according to the target mount directory, and the root directory of the mount directory tree is the target mount directory. Afterwards, a mount request message is obtained, and the mount request message carries mount parameters, and the mount parameters include a second device identifier, a local access directory, and a target device directory. The local access directory is a directory accessed when a file is accessed locally, and the target device directory is a directory in the second device identified by the second device identifier. At least one node is created in the mount directory tree according to the mount request message, and the end of the mount directory indicated by the leaf node in the at least one node is the second device identifier and the target device directory. The local access directory is associated with the mount directory indicated by the leaf node, so that the associated mount between the local access directory and the target device directory in the second device is realized, so that the first device can access the files in the target device directory in the second device through the local access directory, which is convenient for users to use.

[0137] In some embodiments, the device mounting method described above can be implemented by relevant modules in the software systems of the first device and the second device. Figure 6 The software system shown is an exemplary illustration of the device mounting method described above.

[0138] Figure 6 is a block diagram of a software system of a first device and a second device provided in an embodiment of the present application. Figure 6 , the block diagram of the software system can be a zero-layer framework layer.

[0139] The software system of the first device may include an application, a distributed file module, a distributed file service, and a Fuse framework. The distributed file service includes a service module (Service), a mount manager, a data processor, and a Fuse framework adaptation layer. The application, the distributed file module, and the distributed file service may all be located in the application layer. The Fuse framework may be located in the kernel layer.

[0140] The software system of the second device may include a distributed file service and a Fuse framework, wherein the distributed file service includes a service module, a mount manager, and a data processor. The distributed file service may be located at an application layer. The Fuse framework may be located at a kernel layer.

[0141] Among them, for the first device, the application can request the distributed file service to mount by calling the mount interface provided by the distributed file module. After the service module in the distributed file service receives the mount request information sent by the application, it can generate a mount directory tree, and the mount manager performs a mount operation according to the mount directory tree and the mount request information. After the mount is successful, the data processor can synchronize the metadata of the root directory in the second device.

[0142] When an application needs to access a file, it can send a file access request to the Fuse framework through a file library function. After receiving the file access request, the Fuse framework can send the file access request to the Fuse framework adaptation layer. After receiving the file access request, the Fuse framework adaptation layer can perform an attribute query from the data processor to determine whether the file access request meets the relevant attribute requirements. If the file access request meets the relevant attribute requirements, the file access request is sent to the data processor. After receiving the file access request, the data processor accesses the file in the second device according to the metadata of the mounted directory tree and the root directory in the second device.

[0143] The distributed file service in the embodiment of the present application can be used as a public capability to provide a common external interface to the application program, and the application program can select different interfaces for mounting and unmounting according to their respective application scenarios.

[0144] Next, combine Figure 6 The software system shown provides an exemplary description of the device mounting method in the embodiment of the present application.

[0145] The first step is to complete the local file system mounting process after the distributed file service is started up by the application in the closed state.

[0146] The following takes Android devices as an example. Due to the root permission in Android devices, the distributed file service cannot directly call the Fuse framework. Therefore, it is necessary to call the Fuse framework through the vold service to complete the mounting of the local file system.

[0147] in, Figure 7 The following is a schematic diagram showing the basic interface (i.e., IBinder interface) for the distributed file service to obtain the vold service. Figure 7, the distributed file service sends a binder message to the Binder driver in the kernel layer for obtaining the vold service. After receiving the binder message, the Binder driver sends a permission verification request to the SeLinux module in the kernel layer to verify whether the distributed file service has SeLinux permissions. If the distributed file service has SeLinux permissions, the Binder driver sends a vold service acquisition request to the system-server service, and then the system-server service transmits the basic interface of the vold service to the Binder driver, and the Binder driver transmits the basic interface of the vold service to the distributed file service.

[0148] Figure 8 The following figure shows the schematic diagram of how the Fuse framework completes the local file system mounting. Figure 8 , the distributed file service calls the basic interface of the vold service and sends a binder message to the vold service for mounting the local file system. After receiving the binder message, the vold service sends a file open message to the Fuse framework in the kernel layer, and the file open message is used to request to open the fuse device file. After opening the fuse device file, the fuse framework transmits the file descriptor (file descriptor, fd) of the fuse device file to the vold service. The vold service sends a local file system mount request to the Fuse framework based on the file descriptor. After receiving the local file system mount request, the Fuse framework sends a permission verification request to the SeLinux module in the kernel layer to verify whether the vold service has SeLinux permissions. If the vold service has SeLinux permissions, the Fuse framework completes the mounting of the local file system through the fuse device file and returns the mounting result to the vold service. The vold service can return the mounting result to the distributed file service.

[0149] In the second step, the distributed file service creates a mount directory tree.

[0150] Distributed file services can manage mount directories and mount information in memory, as well as manage multiple applications mounting the same device at the same mount point or multiple applications mounting multiple devices at different mount points. Distributed file services will generate a "tree" in memory to manage mount directories, namely the mount directory tree. When the local file system is mounted successfully, the distributed file service can use the directory of the local file system as the root directory to create the mount directory tree.

[0151] Fig. 9The structure of the mount directory tree and its usage in the mount process are shown. The Fuse framework creates a mount directory tree after mounting the local file system. The application can update the mount directory tree after mounting through the distributed file service. The local access directory is associated with the mount directory indicated by the mount directory tree. The mount point in the mount directory tree can mount information.

[0152] In the third step, after the application starts the distributed file service, it can call the interface provided by the distributed file service to check whether the local access directory to be mounted has been mounted. If it has not been mounted, it can call the mounting interface to mount it. The interface input parameters are: the device ID of the peer device to be mounted, the local access directory, the target device directory to be mounted, the file system type, the callback function for receiving the mounting result and the unmounting result, etc. The specific mounting steps are as follows Fig.10 As shown, see Fig.10 The mounting step may include the following steps (1) to (6).

[0153] (1) After the distributed file service calls the mount interface, it will first verify the legality of the input parameters, such as whether the length of the device identifier is legal, whether the directory input is legal, etc. It will then parse the local configuration file to determine whether the application has mount permissions and whether the local access directory exists.

[0154] (2) If it is the first time to mount the device, it is necessary to negotiate with the device for mounting. The negotiation content includes: whether the device supports distributed file capabilities, whether the target device directory exists, whether the distributed file switch of the device is turned on, etc.

[0155] (3) After the negotiation is successful, the mount information needs to be managed, and the target mount directory of the local file system needs to be created, the mount directory tree needs to be generated, and then the server needs to be instructed to initialize.

[0156] Afterwards, the mount manager can determine whether the root directory of the target device directory in its device already exists in the mount directory tree. If it does, the mount manager can add 1 to the reference count in the mount information of the node where the root directory of the target device directory in its device is located, and add the application identifier. If it does not exist, a node is created in the mount directory tree, and the mount directory indicated by the node is: target mount directory + group information + device identifier + root directory in the target device directory, and mount information is created for the node where the root directory in the target device directory is located.

[0157] Afterwards, the metadata of the root directory of the target device directory in its device is obtained, and the metadata is stored locally.

[0158] (4) Create a node in the mount directory tree. The mount directory indicated by the node is: target mount directory + group information + device identifier + target device directory.

[0159] (5) Associate the file access directory with the mount directory indicated by the mount directory tree.

[0160] (6) Call back the mounting result to the application.

[0161] It should be noted that there are two types of mount interfaces: one is for mounting a single directory on a single device, and the other is for mounting multiple directories on a single device, i.e., batch mount interfaces. There are also two types of batch mount interfaces: one is atomic batch mount, where all directories fail to mount if one directory fails to mount; the other is non-atomic batch mount, where other directories do not get affected if one directory fails to mount. Regardless of whether the mount succeeds or fails, the distributed file service will notify the application of the mount result through a callback. If the mount fails, the error code will be used to notify the application of the reason for the mount failure.

[0162] Step 4: When the application performs the uninstallation operation, the reference count of the uninstallation directory is first reduced by 1. If the reference count is not 0, the association between the local access directory and the uninstallation directory is only cancelled, and the directory is not actually uninstalled. The uninstallation operation is not actually performed until the reference count is 0. The specific uninstallation steps are as follows: Fig.11 As shown, see Fig.11 , the unloading step may include the following steps (1) to (2).

[0163] (1) The application sends an unmount request to the mount manager through the distributed file service module.

[0164] (2) The mount manager determines whether the directory to be unmounted has been mounted. If it has been mounted, the reference count of the unmounted directory is reduced by 1. If the reference count is not 0, a non-real unmount is performed. If the reference count is 0, a real unmount is performed. The unmount result is then returned.

[0165] The operation of non-real uninstallation can be: deleting related nodes and canceling the association between the local access directory and the uninstallation directory. The operation of real uninstallation can be: deleting related nodes, instructing the server to uninstall, then clearing the local data cache, and then canceling the association between the local access directory and the uninstallation directory.

[0166] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website site, computer, server or data center by wired (such as: coaxial cable, optical fiber, data subscriber line (Digital Subscriber Line, DSL)) or wireless (such as: infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access, or a data storage device such as a server or data center that includes one or more available media integrations. The available medium may be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a digital versatile disc (DVD)), or a semiconductor medium (such as a solid state disk (SSD)).

[0167] The above are optional embodiments provided for the present application and are not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the technical scope disclosed in the present application shall be included in the protection scope of the present application.

Claims

1. A device mounting method, characterized in that: Applied to a first device, the method includes: Mounting a local file system, wherein the directory of the local file system is the target mounting directory; Generate a mount directory tree according to the target mount directory, the root directory of the mount directory tree being the target mount directory; Obtaining mount request information, the mount request information carrying mount parameters, the mount parameters including a second device identifier, a local access directory, and a target device directory, the local access directory being a directory accessed when a file is accessed locally, and the target device directory being a directory in the second device identified by the second device identifier; Creating at least one node in the mount directory tree according to the mount request information, wherein the end of the mount directory indicated by the leaf node in the at least one node is the second device identifier and the target device directory; The local access directory is associated with the mount directory indicated by the leaf node.

2. The method according to claim 1, characterized in that Before creating at least one node in the mount directory tree according to the mount request information, the method further includes: Performing a validity check on the mount parameters; If the legitimacy check of the mount parameters passes, then when the application that generates the mount request information has mount permission and the local access directory exists, the operation of creating at least one node in the mount directory tree according to the mount request information is performed.

3. The method according to claim 1, characterized in that Before creating at least one node in the mount directory tree according to the mount request information, the method further includes: Performing a mount negotiation with the second device, and executing the operation of creating at least one node in the mount directory tree according to the mount request information if the mount negotiation with the second device is successful; Among them, when the second device is not currently mounted, the mount negotiation content with the second device includes: whether the second device supports distributed file capabilities, whether the target device directory exists in the second device, and whether the distributed file switch of the second device is turned on; when the second device is currently mounted, the mount negotiation content with the second device includes: whether the target device directory exists in the second device and whether the distributed file switch of the second device is turned on.

4. The method according to any one of claims 1 to 3, characterized in that: Before creating at least one node in the mount directory tree according to the mount request information, the method further includes: If the first node does not exist in the mount directory tree, the step of creating at least one node in the mount directory tree according to the mount request information is performed, the data of the first node is the root directory of the target device directory, and the data of the parent node of the first node is the second device identifier, and the at least one node includes the first node; Create mount information for the first node in the mount directory tree, the mount information including a reference count, a device identifier and an application identifier, the reference count is 1, the device identifier is the second device identifier, and the application identifier is the identifier of the application that generates the mount request information.

5. The method according to any one of claims 1 to 3, characterized in that: Before creating at least one node in the mount directory tree according to the mount request information, the method further includes: If there is a first node in the mount directory tree, the reference count in the mount information of the first node is increased by 1, and the identifier of the application that generates the mount request information is added to the application identifier in the mount information of the first node, and the step of creating at least one node in the mount directory tree according to the mount request information is executed, the data of the first node is the root directory of the target device directory, and the data of the parent node of the first node is the second device identifier.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: Obtaining an uninstallation request message, wherein the uninstallation request message carries the file access directory; Unmount the mount directory associated with the file access directory.

7. The method according to claim 6, characterized in that The step of unmounting the mount directory associated with the file access directory includes: Determine a mount directory associated with the file access directory as a second directory; Decrement the reference count in the mount information of the third node by 1, wherein the third node is a node having mount information among all nodes constituting the second target in the mount directory tree; If the reference count in the mount information of the third node is not 0 after being decremented by 1, the association between the mount directory indicated by the third node and the nodes under the third node in the mount directory tree and the file access directory corresponding to the application that generated the uninstall request message is cancelled.

8. The method according to claim 7, characterized in that After the reference count in the mount information of the third node is reduced by 1, the method further includes: If the reference count in the mount information of the third node is reduced by 1 and becomes 0, the parent node of the third node, the third node and all nodes under the third node in the mount directory tree are deleted, and the association between the mount directory indicated by the deleted node and the file access directory is cancelled, and an uninstall message is sent to the device identified by the data of the parent node of the third node.

9. An electronic device, characterized in that: The electronic device comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the method according to any one of claims 1 to 8 when executed by the processor.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the method according to any one of claims 1 to 8.

Images