Device mounting methods, electronic devices and computer-readable storage media

Abstract

This application discloses a device mounting method, an electronic device, and a computer-readable storage medium, belonging to the field of mounting technology. The method includes: mounting a local file system; generating a mount directory tree based on a target mount directory, the root directory of which is the target mount directory; obtaining mount request information, which includes a second device identifier, a local access directory, and a target device directory; creating at least one node in the mount directory tree based on the mount request information, where the leaf nodes of the at least one node indicate mount directories ending with the second device identifier and the target device directory; and associating the local access directory with the mount directory indicated by the leaf node. This application achieves the associated mounting between the local access directory and the target device directory in the second device, thereby enabling the first device to access files in the target device directory of the second device through the local access directory.

Description

Technical Field

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

[0002] Currently, people frequently save numerous files in their daily work and life. For example, office workers, researchers, and university students need to save many documents such as office summaries, research reports, and study materials. These files are often distributed across different devices such as mobile phones, tablets, and laptops. When using these files, users often need to browse files across devices, search for files across devices, or transfer files across devices. Summary of the Invention

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

[0004] Firstly, a device mounting method is provided. In this method, a first device mounts a local file system, the directory of which is the target mount directory. A mount directory tree is generated based on the target mount directory, with the root directory of the mount directory tree being the target mount directory. Then, mount request information is obtained, carrying mount parameters including a second device identifier, a local access directory, and a target device directory. The local access directory is the directory accessed when accessing files locally, and the target device directory is a directory within the second device identified by the second device identifier. At least one node is created in the mount directory tree based on the mount request information, where the end of the mount directory indicated by the leaf node of the at least one node is the second device identifier and the target device directory. The local access directory is then associated with the mount directory indicated by the leaf node.

[0005] In this application, the association 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 based on the mount request information, the mount parameters can be validated for validity. If the validation of the mount parameters passes, and provided that the application that generated the mount request information has mount permissions and the local access directory exists, the operation of creating at least one node in the mount directory tree based on the mount request information can be performed. This can improve the mount success rate.

[0007] Optionally, before creating at least one node in the mount directory tree based on the mount request information, mount negotiation can be performed with the second device. If the mount negotiation is successful, the operation of creating at least one node in the mount directory tree based on the mount request information can be executed. This can improve the mount success rate.

[0008] The negotiation content with the second device when the second device is not currently mounted includes: whether the second device supports distributed file capability, whether the target device directory exists in the second device, and whether the distributed file switch of the second device is turned on; the negotiation content with the second device when the second device is currently mounted 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 based on the mount request information, the following operations may also be performed: if the first node does not exist in the mount directory tree, then the step of creating at least one node in the mount directory tree based on the mount request information is performed, wherein 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; mount information is created for the first node in the mount directory tree, wherein the mount information includes a reference count, a device identifier, and an application identifier, wherein the reference count is 1, the device identifier is the second device identifier, and the application identifier is the identifier of the application that generated the mount request information.

[0010] If the first node does not exist in the mount directory tree, it indicates that the target device directory in the second device is being mounted for the first time. Therefore, at least one node can be created in the mount directory tree to mount the target device directory in the second device. Furthermore, 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 based on the mount request information, the following operations may also be performed: if a first node exists in the mount directory tree, increment the reference count in the mount information of the first node by 1, and add the identifier of the application that generated the mount request information to the application identifier in the mount information of the first node, and perform the step of creating at least one node in the mount directory tree based on the mount request information, wherein 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 a first node exists in the mount directory tree, it means that the root directory in the target device directory of the second device has been mounted. Therefore, the reference count in the mount information of the first node can be incremented by 1, and at least one node can be created in the mount directory tree to mount the target device directory of 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 as follows: determine the mount directory associated with the file access directory as the second directory; decrement the reference count in the mount information of the third node by 1, where the third node is the node with 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 decrementing by 1, then cancel the association between the third node in the mount directory tree and the mount directory indicated by the third node and the file access directory corresponding to the application that generated the uninstallation request message.

[0015] Optionally, after decrementing 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 becomes 0 after decrementing by 1, then delete the parent node of the third node, the third node, and all nodes under the third node in the mount directory tree, and cancel the association between the mount directory indicated by the deleted node and the file access directory, and send an unmount message to the device identified by the data of the parent node of the third node.

[0016] In this application, it can be determined whether the directory to be uninstalled is already mounted. If it is mounted, the reference count of the uninstallation directory is decremented by 1. If the reference count is not 0, a non-real uninstallation is performed; if the reference count is 0, a real uninstallation is performed. Then, the uninstallation result is returned. The non-real uninstallation operation can be: deleting the relevant nodes and canceling the association between the local access directory and the uninstallation directory. The real uninstallation operation can be: deleting the relevant nodes, instructing the server to perform the uninstallation, then clearing the local data cache, and then canceling the association between the local access directory and the uninstallation directory.

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

[0018] Thirdly, an electronic device is provided, comprising a processor and a memory. The memory stores a program that supports the electronic device in executing the device mounting method provided in the first aspect, and stores data related to 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 further include a communication bus for establishing a connection between the processor and the memory.

[0019] Fourthly, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the device mounting method described in the first aspect.

[0020] Fifthly, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to execute the device mounting method described in the first aspect.

[0021] The technical effects achieved by the second, third, fourth, and fifth aspects mentioned above are similar to those achieved by the corresponding technical means in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

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

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

[0025] Figure 4 This is a schematic diagram of a mounted directory tree provided in an embodiment of this application;

[0026] Figure 5 This is a flowchart of a device mounting method provided in an embodiment of this application;

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

[0028] Figure 7 This is a schematic diagram of a basic interface for obtaining vold services provided in an embodiment of this application;

[0029] Figure 8 This is a schematic diagram illustrating how the Fuse framework completes the mounting of a local file system, as provided in an embodiment of this application.

[0030] Figure 9 This is a schematic diagram illustrating the structure of a mounted directory tree and its usage position in the mounting process, as provided in an embodiment of this application.

[0031] Figure 10 This is a schematic diagram of a mounting step provided in an embodiment of this application;

[0032] Figure 11 This is a schematic diagram of an uninstallation step provided in an embodiment of this application. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0034] It should be understood that "multiple" as mentioned in this application refers to two or more. In the description of this application, unless otherwise stated, " / " indicates "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, to facilitate a clear description of the technical solutions of this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0035] The terms "one embodiment" or "some embodiments" used in this application mean that one or more embodiments of this application include the specific features, structures, or characteristics described in that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this application do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. Furthermore, the terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0036] The electronic devices involved in the embodiments of this application will be described below.

[0037] Figure 1 This is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of this application. See also... 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, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity 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 understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

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

[0040] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0041] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from this memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0042] The external storage 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 storage interface 120 to perform data storage functions, such as saving music, video, and other files on the external memory card.

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

[0044] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, or USB Type-C port. USB port 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback. USB port 130 can also be used to connect other devices, such as AR devices.

[0045] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via a USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the electronic device 100. While charging the battery 142, the charging management module 140 can also supply power to the electronic device 100 via the power management module 141.

[0046] The power management module 141 connects 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 supplies power to the processor 110, internal memory 121, external memory, display screen 194, camera 193, and wireless communication module 160, etc. The power management module 141 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 141 may also be located within the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be located in the same device.

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

[0048] Antennas 1 and 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0049] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0050] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. 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 antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0051] Electronic device 100 implements display functions through a GPU, a display screen 194, and an 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 and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0052] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be 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 LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is an integer greater than 1.

[0053] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0054] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's image sensor. The light signal is converted into an electrical signal, and the image sensor transmits the electrical signal to the ISP for processing, transforming it into an image visible to the naked eye. The ISP can also perform algorithmic optimizations on image noise, brightness, and skin tone. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be integrated into the camera 193.

[0055] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the electronic device 100 may include one or N cameras 193, where N is an integer greater than 1.

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

[0057] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0058] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch buttons. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100.

[0059] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. For example, different vibration feedback effects can be corresponding to touch operations applied to different applications (such as taking photos, playing audio, etc.). Touch operations applied to 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 be customized.

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

[0061] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with and separate from the electronic device 100. The electronic device 100 can support one 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, etc. Multiple cards can be inserted into the same SIM card interface 195 simultaneously. The multiple cards can be of the same or different types. The SIM card interface 195 is also compatible with different types of SIM cards. The SIM card interface 195 is also compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to realize functions such as calls and data communication. 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] The software system of electronic device 100 will be described next.

[0063] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses a layered Android system as an example to illustrate the software system of electronic device 100.

[0064] Figure 2 This is a block diagram of a software system for an electronic device 100 provided in an embodiment of this application. See also... Figure 2 A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into an application layer, an application framework layer, the Android Runtime, a system layer, and a kernel layer.

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

[0066] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions. For example... Figure 2As shown, the application framework layer can include a window manager, content providers, a view system, a phone manager, a resource manager, and a notification manager. The window manager manages window programs. It can obtain the screen size, determine if a status bar is present, lock the screen, and capture the screen. The content provider stores and retrieves data, making this data accessible to the application. This data can include videos, images, audio, made and received phone calls, browsing history and bookmarks, and phone books. The view system includes visual controls, such as controls for displaying text and controls for displaying images. The view system can be used to build the application's display interface, which can consist of one or more views, such as a view displaying SMS notification icons, a view displaying text, and a view displaying images. The phone manager provides communication functions for the electronic device 100, such as managing call status (including connection and disconnection). The resource manager provides the application with various resources, such as localized strings, icons, images, layout files, and video files. The notification manager allows the application to display notification information in the status bar, which can be used to convey informational messages and can disappear automatically after a short pause without user interaction. For example, the notification manager is used to notify users of download completions and message alerts. The notification manager can also display notifications as icons or scrolling text in the system's top status bar, such as notifications from background applications. Furthermore, the notification manager can appear as dialog boxes on the screen, such as displaying text messages in the status bar, emitting sounds, causing electronic devices to vibrate, or flashing indicator lights.

[0067] The Android Runtime comprises the core libraries and the virtual machine. The Android Runtime is responsible for the scheduling and management of the Android system. The core libraries consist of two parts: one part contains the functionalities that Java calls, and the other part is the core Android library itself. The application layer and application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0068] The system layer can include multiple functional modules, such as a surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), and 2D graphics engines (e.g., SGL). The surface manager manages the display subsystem and provides fusion of 2D and 3D layers for multiple applications. The media libraries support playback and recording of various common audio and video formats, as well as still image files. They support multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG. The 3D graphics processing libraries implement 3D graphics drawing, image rendering, compositing, and layer processing. The 2D graphics engine is the drawing engine for 2D graphics.

[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 this application are described below.

[0071] Currently, people frequently save numerous files in their daily work and life. For example, office workers, researchers, and university students need to save many documents such as office summaries, research reports, and study materials. These files are often distributed across 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] Therefore, this application provides a distributed system. This distributed system includes multiple devices, and any two of these devices have the ability to access each other, thus enabling cross-device browsing, searching, and file transfer.

[0073] The distributed system provided in the embodiments of this application will be described below.

[0074] Figure 3 This is a schematic diagram of a distributed system provided in an embodiment of this application. See also... Figure 3 The distributed system comprises multiple devices 300.

[0075] Any one of the multiple devices 300 can be described above. Figures 1 to 2 The electronic device 100 described in the embodiments, for example, any one of the plurality of devices 300 can be a mobile phone, PDA, PC, etc., and the embodiments of this application do not limit this.

[0076] Any one of the multiple devices 300 (referred to as the second device) can be mounted to another device 300 (referred to as the first device). In this case, the first device can act as a client, and the second device can act as a server. The server is mounted to the client, and the client can access files on the server.

[0077] The multiple devices 300 can have multiple clients or multiple servers. Furthermore, any one of the multiple devices 300 can be both a client and a server. In other words, any one of the multiple devices 300 can be connected to other devices 300 or connected to other devices 300.

[0078] Optionally, any one of the multiple devices 300 can have multiple applications (also referred to as business applications). These multiple applications can apply to mount other devices 300 onto this device 300, and the other devices 300 that the multiple applications apply to mount can be the same device or different devices. These multiple applications can access files on the devices 300 they are mounted to. For example, these multiple applications may include file managers, workstations, gallery applications, etc., but this embodiment does not limit this to a single application.

[0079] The mounting directory tree involved in the embodiments of this application will be described below.

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

[0081] Figure 4 This is a schematic diagram of a mounted directory tree provided in an embodiment of this application. For example... Figure 4 As shown, the mounted directory tree is a tree structure. The data in each node of the mounted directory tree is a directory. The data in the root node of the mounted directory tree can be called the root directory, and the data in other nodes of the mounted directory tree can be called subdirectories.

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

[0083] Each node in the mount directory tree indicates a mount directory, or mount point. For example, the mount directories indicated by the nodes in the mount directory tree can be disk directories.

[0084] The root node of the mount directory tree indicates the root directory of the mount directory tree, which is also the directory of the local file system and the mount point of the local file system. Other nodes in the mount directory tree, besides the root node, indicate the mount directories of other devices, i.e., the mount points of other devices. The mount directory indicated by any node in the mount directory tree, excluding the root node, is a directory consisting of the data of all nodes along the path from the root node to that node.

[0085] for example, Figure 4 The root node of the mount directory tree shown indicates the mount directory " / mnt / appfuse / dfs". The nodes in the next level down from the root node indicate the mount directories " / mnt / appfuse / dfs / " and " / mnt / appfuse / dfs / default", respectively. The nodes in the next level down indicate the mount directories " / mnt / appfuse / dfs / default / device1" and " / mnt / appfuse / dfs / default / device2", respectively. The nodes in the next level down indicate the mount directories " / mnt / appfuse / dfs / default / device1 / sdcard" and " / mnt / appfuse / dfs / default / device2 / sdcard", respectively. The nodes in the next level down indicate the mount directory " / mnt / appfuse / dfs / default / device2 / sdcard / memory".

[0086] In this system, the mount directory tree contains mount directories that contain the target device directory, and these mount directories are other devices. The target device directory is a directory within one of those other devices. For example, Figure 4The mount directory tree shown contains mount directories " / mnt / appfuse / dfs / default / device1 / sdcard" and " / mnt / appfuse / dfs / default / device2 / sdcard", both ending with the target device directory " / sdcard". Similarly, the mount directory " / mnt / appfuse / dfs / default / device2 / sdcard / memory" ends with the target device directory " / sdcard / memory". The root directory within the target device directory " / sdcard" is " / sdcard", and the root directory within the target device directory " / sdcard / memory" is also " / sdcard".

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

[0088] The mounting information of a node may include reference count, device identifier (also known as device ID (IdentityDocument)), application identifier, and may further include read and write permissions, etc.

[0089] The reference count represents the number of times the mount directory indicated by this node has been mounted by an 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 mounted the mount directory indicated by this node, such as the application's package name. The read / write permissions refer to the read and write permissions for files in the mount directory indicated by this node, which can include read-only, write-only, or read / write.

[0090] The device mounting method involved in the embodiments of this application will be described below.

[0091] Figure 5 This is a flowchart illustrating a device mounting method provided in an embodiment of this application. See also... Figure 5 The method includes the following steps:

[0092] Step 501: Mount the local file system on the first device.

[0093] This local file system is the file system in the first device used to mount other devices. After mounting the local file system, the first device can use it to mount other devices. For example, the local file system can be a disk file system, etc., but this application embodiment does not limit it to this only.

[0094] The first device can mount the local file system based on the target mount directory. The target mount directory is the directory of the local file system. Furthermore, the target mount directory is the mount point of the local file system on the first device, and also the mount point of any other devices subsequently mounted on the first device. For example, the target mount directory can be pre-defined, such as / mnt / appfuse / dfs.

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

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

[0097] The root node of the mount directory tree represents the target mount directory. The mount directory indicated by this root node is the target mount directory, which is also the mount point for the local file system. Other nodes in the mount directory tree, besides the root node, indicate the mount directories of other devices, i.e., the mount points for those devices. The mount directory indicated by any node in the mount directory tree, excluding the root node, is a directory composed of the data from all nodes along the path from the root node to that node.

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

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

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

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

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

[0103] In this configuration, the second device identifier is the identifier of the second device to be mounted according to the mount request information. The local access directory is the directory accessed locally when accessing files, that is, the directory accessed by the application that generated the mount request information when accessing files. The target device directory is a directory within the second device to be mounted according to the mount request information. The file system type is the type of the local file system. In this case, after successful mounting according to the mount request information, the application on the first device can access files in the target device directory on the second device by accessing the local access directory.

[0104] As an example, the local access directories mounted by different applications on the first device can be different. In this case, before generating a mount request, the application can first check whether the local access directory it wants to mount is already mounted. If the local access directory is not mounted, the application can generate a mount request. If the local access directory is already mounted, the application cannot mount it. In this case, the application can choose not to generate a mount request, or it can try to change to another local access directory and generate a mount request only if the changed local access directory is not mounted.

[0105] In some cases, after obtaining the mount request information, the first device can verify the validity 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 valid, and whether the formats of the local access directory and the target device directory in the mount request information are valid.

[0106] If the validity check of the mount parameters in the mount request information fails, the first device will not continue to execute step 504 below, but will directly determine the mount result as a mount failure and send 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 may also carry an error code, which is used to indicate the reason for the mount failure.

[0107] If the validity verification of the mount parameters in the mount request information passes, the first device can further determine whether the application that generated the mount request information has mount permissions, and 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 permissions based on the local configuration file. If the application has mount permissions and the local access directory exists, the first device can continue to execute step 504 below; otherwise, the first device will not continue to execute step 504 below, but will directly determine that the mount result is a mount failure and send the mount result to the application.

[0108] In this case, the first device will only perform the mounting operation if the mounting parameters in the mounting request information are valid, the application has mounting permissions, and the local access directory exists, thereby improving the mounting success rate.

[0109] In some cases, the first device can negotiate a mount with the second device before executing step 504. If the mount negotiation with the second device is successful, the first device continues to execute step 504, which can improve the mount success rate. If the mount negotiation with the second device fails, the first device does not continue to execute 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 mounting negotiation between the first and second devices includes: whether the second device supports distributed file capabilities, whether the target device directory exists on the second device, and whether the distributed file switch is enabled on the second device. If the second device supports distributed file capabilities, the target device directory exists on the second device, and the distributed file switch is enabled on the second device, then the mounting negotiation between the first and second devices is considered successful; otherwise, the mounting negotiation between the first and second devices is considered to have failed.

[0111] If the second device is already mounted, the mount negotiation between the first and second devices includes: whether the target device directory exists on the second device, and whether the distributed file switch on the second device is enabled. If the target device directory exists on the second device and the distributed file switch on the second device is enabled, the mount negotiation between the first and second devices is considered successful; otherwise, the mount negotiation between the first and second devices is considered to have failed.

[0112] The distributed file capability is used to indicate that the electronic device supports the device mounting scheme provided in the embodiments of this application. If the second device supports the distributed file capability, then the second device is... Figure 3 The distributed system shown includes an electronic device 300, and a second device that supports mounting 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 scheme provided in this application embodiment. If the distributed file switch in the second device is turned on, it means that the second device currently allows itself to be mounted to 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 to other devices.

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

[0115] The order from the first node to the last node in the at least one node is the same as the order from the topmost node to the bottommost node in the at least one node. In this case, the mount directory indicated by the last node (i.e., the leaf node) in the at least one node ends in the first directory, which ends in the target device directory. The first directory may also contain target subdirectories, which are second device identifiers and are the parent directories of the target device directory. For example, the first directory may also contain specified subdirectories, which are the parent directories of the target subdirectories. The specified subdirectories can be preset; for example, the specified subdirectories can be preset group information, which can be default. This 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 at least one node in the mount directory tree, mounting the target device directory on the second device can be achieved. Furthermore, this local access directory is associated with the mount directory indicated by the leaf node of the at least one node. Thus, the associated mount of the local access directory and the target device directory on 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 on the second device according to that mount directory.

[0118] In some embodiments, after performing 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 "first directory", it indicates that the target device directory in the second device has already been mounted. In this case, the first device can skip steps 504 and 505, instead incrementing the reference count in the mount information of the first node, adding the identifier of the application that generated the mount request information to the application identifier in the mount information of the first node, and associating the file access directory with the mount directory ending with "first directory" in the mount directory tree. Here, 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 identifier of the second device.

[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 then 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 ending with the first directory in the mount directory tree (i.e., the mount directory indicated by the leaf node in the at least one node mentioned above).

[0121] Furthermore, if the mount directory tree does not contain a mount directory ending with "first directory", before executing steps 504 and 505, the first device can determine whether a first node exists in the mount directory tree. If a first node exists in the mount directory tree, the first device can increment the reference count in the mount information of the first node by 1, and add the identifier of the application that generated the mount request information to the application identifier in the mount information of the first node, and then execute steps 504 and 505. If a first node does not exist in the mount directory tree, the first device can execute steps 504 and 505. In this case, the at least one node includes the first node, 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 generated the mount request information, and the read / write permissions in the mount information are the read / write permissions of the target device directory in the second device.

[0122] Furthermore, after performing the above operations, the first device can send an initialization message to the second device, which may carry the target device directory. Upon receiving the initialization message, the second device can initialize its own mount service and obtain the metadata of the root directory in the target device directory, then send this metadata to the first device. The first device can then store this metadata.

[0123] After successfully mounting the file access directory to the target device directory in the second device, the first device can determine that the mount result is successful. The first device can send the mount result to the application that generated the mount request information; for example, it can send the mount result to the application according to the callback function in the mount request information.

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

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

[0126] Alternatively, the application can generate a mount command containing multiple mount request messages. After the first device obtains the mount command, it can perform the mount operation for each mount request message in the mount command according to steps 503 to 505 described above. In this case, if it is an atomic batch directory mount, and at least one mount request message in the mount command fails to mount, it can be determined that the mount results of all mount request messages in the mount command are mount failures. If it is a non-atomic batch directory mount, the mount results of each mount request message in the mount command will not affect each other.

[0127] It should be noted that when an application associates and mounts the file access directory with the target device directory in the second device, if the application wants to access a 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 according to the mount directory. This access can be file reading or writing.

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

[0129] In the first scenario, the first device can unload all directories on the third device when the third device disconnects from the first device.

[0130] The third device is a device other than the first device. Optionally, if either the first device or the third device goes offline, the connection between the first device and the third device will be disconnected.

[0131] The operation of the first device to unload all directories in the third device can be as follows: The first device deletes the node in the mount directory tree where the third device is identified, as well as all nodes under that node, and cancels the association between the mount directory indicated by the deleted nodes and the file access directory.

[0132] In the second scenario, the first device can unload the directory mounted by the application when the application is uninstalled, or when the application crashes, exits, and does not access files.

[0133] The operation of the first device to unload the directory mounted by the application can be as follows: The first device decrements the reference count of the second node in the mount information of the mount directory tree by 1. The second node is the node whose application identifier exists in the application identifier in the mount information. If the reference count of the second node's mount information becomes 0 after decrementing by 1, then the parent node of the second node, the second node itself, and all nodes under the second node are deleted from the mount directory tree. The association between the mount directories indicated by these deleted nodes and the file access directory is also canceled. Furthermore, an unload message is sent to the device identified by the data of the parent node of the second node. Upon receiving the unload message, the device can stop the relevant service. If the reference count of the second node's mount information is not 0 after decrementing by 1, then the association between the mount directories indicated by the second node and all nodes under the second node and the file access directory corresponding to the application is canceled.

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

[0135] The first device can perform the following operation to unload the mounted directory associated with the file access directory: The first device determines the mounted directory associated with the file access directory as the second directory, decrements the reference count in the mount information of the third node by 1, and the third node is the node with mount information among all nodes constituting the second directory in the mount directory tree; if the reference count in the mount information of the third node is 0 after decrementing by 1, then the parent node of the third node, the third node, and all nodes under the third node are deleted from the mount directory tree, and the association between the mounted directories indicated by these deleted nodes and the file access directory is canceled, and an unload 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 unload message; if the reference count in the mount information of the third node is not 0 after decrementing by 1, then the association between the mounted directories indicated by the third node and all nodes under the third node and the file access directory corresponding to the application is canceled.

[0136] In this embodiment, the first device mounts a local file system, the directory of which is the target mount directory. A mount directory tree is generated based on the target mount directory, with the root directory of the tree being the target mount directory. Then, mount request information is obtained, carrying mount parameters including a second device identifier, a local access directory, and a target device directory. The local access directory is the directory accessed locally for file access, and the target device directory is a directory within the second device identified by the second device identifier. At least one node is created in the mount directory tree based on the mount request information. The leaf nodes of these nodes indicate mount directories ending with the second device identifier and the target device directory. The local access directory is associated with the mount directory indicated by the leaf node. This establishes an association between the local access directory and the target device directory within the second device, allowing the first device to access files within the target device directory on the second device via the local access directory, facilitating user access.

[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. The following describes the implementation method in conjunction with... Figure 6 The software system shown is an example of the device mounting method described above.

[0138] Figure 6 This is a block diagram of a software system for a first device and a second device provided in an embodiment of this application. See also... Figure 6 The block diagram of this software system can be a zero-layer framework layer.

[0139] The software system of the first device may include an application program, a distributed file module, a distributed file service, and the Fuse framework. The distributed file service includes a service module, a mount manager, a data processor, and a Fuse framework adaptation layer. The application program, distributed file module, and distributed file service can all reside at the application layer. The Fuse framework can reside at the kernel layer.

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

[0141] For the first device, the application can request mounting from the distributed file service by calling the mount interface provided by the distributed file module. After receiving the mount request from the application, the service module in the distributed file service can generate a mount directory tree, and the mount manager performs the mount operation based on the mount directory tree and the mount request information. After successful mounting, 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 using file library functions. Upon receiving the request, the Fuse framework forwards it to the Fuse framework adapter layer. The adapter layer then performs an attribute query from the data processor to determine if the request meets the relevant attribute requirements. If it does, the adapter layer forwards the request to the data processor. The data processor, upon receiving the request, accesses the file on the second device based on the metadata of the mounted directory tree and the root directory in the second device.

[0143] The distributed file service in this embodiment can serve as a public capability, providing a general external interface to applications. Applications can choose different interfaces to mount and unmount files according to their respective application scenarios.

[0144] Next, combine Figure 6 The software system shown here is an exemplary illustration of the device mounting method in the embodiments of this application.

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

[0146] The following explanation uses an Android device as an example. Due to root privileges, the distributed file service on an Android device cannot directly call the Fuse framework. Therefore, it is necessary to use the vold service to call the Fuse framework to complete the mounting of the local file system.

[0147] in, Figure 7 This diagram illustrates the basic interface (IBinder interface) through which a distributed file service obtains the vold service. See also... Figure 7The distributed file service sends a binder message to the Binder driver in the kernel layer to retrieve the vold service. Upon receiving this 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 retrieval request to the system-server service. The system-server service then transmits the basic interface of the vold service to the Binder driver, which in turn transmits the basic interface of the vold service to the distributed file service.

[0148] Figure 8 This diagram illustrates how the Fuse framework completes the local file system mounting process. See also... Figure 8 The distributed file service calls the basic interface of the vold service, sending a binder message to the vold service for mounting the local file system. Upon receiving this binder message, the vold service sends a file open message to the Fuse framework in the kernel layer, requesting to open the fuse device file. After opening the fuse device file, the Fuse framework transmits the file descriptor (fd) of the fuse device file to the vold service. The vold service then sends a local file system mount request to the Fuse framework based on this file descriptor. Upon 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 mount result to the vold service. The vold service can then return this mount result to the distributed file service.

[0149] The second step is for the distributed file service to create 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 mount point on the same device or multiple applications mounting different mount points on different devices. Distributed file services generate a "tree" in memory to manage mount directories, i.e., a mount directory tree. Once the local file system is successfully mounted, the distributed file service can use the local file system's directory as the root directory to create the mount directory tree.

[0151] Figure 9This illustrates the structure of the mount directory tree and its usage within the mount process. The Fuse framework creates the mount directory tree after mounting the local file system. Applications can update the mount directory tree after mounting via a distributed file service. Local access directories are associated with the mount directories indicated by the mount directory tree. Mount points in the mount directory tree can mount information.

[0152] Thirdly, after starting the distributed file service, the application can call the interface provided by the distributed file service to query whether the local access directory to be mounted is already mounted. If not, the mounting interface can be called to mount it. The interface parameters are: the device identifier of the peer device to be mounted, the local access directory, the target device directory to be mounted, the file system type, and callback functions for receiving the mount and unmount results. The specific mounting steps are as follows: Figure 10 As shown, see Figure 10 The mounting process may include steps (1) to (6) below.

[0153] (1) After the distributed file service is called on the mount interface, it first checks the validity of the input parameters, such as whether the length of the device identifier is valid and whether the directory input is valid. Then it parses 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 another device, you need to negotiate the mounting with the other device. The negotiation content includes: whether the other device supports distributed file capability, whether the target device directory exists, and whether the distributed file switch of the other device is turned on.

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

[0156] Next, the mount manager can determine whether the root directory of the target device directory on its device already exists in the mount directory tree. If it does, the mount manager increments the reference count in the mount information of the node containing the root directory of the target device directory on its device and adds the application identifier. If it does not exist, it creates a node in the mount directory tree, indicating the mount directory as: target mount directory + group information + device identifier + root directory in the target device directory, and creates mount information for the node containing the root directory in the target device directory.

[0157] Next, it retrieves the metadata of the root directory of the target device directory on its device and stores the metadata locally.

[0158] (4) Create a node in the mount directory tree. The mount directory indicated by this 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) Send the mounting result back to the application.

[0161] It should be noted that the mount interface is divided into two types: one is mounting a single directory on a single device, and the other is mounting multiple directories on a single device, i.e., the batch mount interface. The batch mount interface is also divided into two types: one is atomic batch mount, where if one directory fails to mount, all directory mounts fail; the other is non-atomic batch mount, where if one directory fails to mount, it does not affect the mounting of other directories. Regardless of whether the mount succeeds or fails, the distributed file service will inform the application of the mount result via callback. If the mount fails, it will indicate the reason for the failure through an error code.

[0162] Fourth, when the application performs an uninstallation operation, the reference count of the uninstallation directory is decremented by 1. If the reference count is not 0, only the association between the local access directory and the uninstallation directory is removed; the directory is not actually uninstalled. The uninstallation operation is only performed when the reference count reaches 0. The specific uninstallation steps are as follows: Figure 11 As shown, see Figure 11 The uninstallation process may include steps (1) to (2) below.

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

[0164] (2) The mount manager determines whether the directory to be uninstalled is already mounted. If it is mounted, it decrements the reference count of the directory to be uninstalled by 1. If the reference count is not 0, it performs a non-real uninstallation. If the reference count is 0, it performs a real uninstallation. Then it returns the uninstallation result.

[0165] The non-real uninstallation operation can be: deleting the relevant nodes and canceling the association between the local access directory and the uninstallation directory. The real uninstallation operation can be: deleting the relevant 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, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as 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, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line, DSL) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer, or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

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

Claims

1. A method for mounting equipment, characterized in that, Applied to a first device, the method includes: Mount a local file system, where the directory of the local file system is the target mount directory; A mount directory tree is generated based on the target mount directory, and the root directory of the mount directory tree is the target mount directory; Obtain mount request information, which carries mount parameters, including a second device identifier, a local access directory, and a target device directory. The local access directory is the directory accessed when accessing files 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 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; Associate the local access directory with the mount directory indicated by the leaf node.

2. The method as described in claim 1, characterized in that, Before creating at least one node in the mount directory tree based on the mount request information, the method further includes: The validity of the mounting parameters is verified. If the validity of the mount parameters passes the verification, and the application that generated the mount request information has mount permissions and the local access directory exists, the operation of creating at least one node in the mount directory tree based on the mount request information is executed.

3. The method as described in claim 1, characterized in that, Before creating at least one node in the mount directory tree based on the mount request information, the method further includes: Perform mount negotiation with the second device, and if the mount negotiation with the second device is successful, perform the operation of creating at least one node in the mount directory tree based on the mount request information; The mounting negotiation with the second device when the second device is not currently mounted includes: whether the second device supports distributed file capability, whether the target device directory exists in the second device, and whether the distributed file switch of the second device is turned on; the mounting negotiation with the second device when the second device is currently mounted 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 based on the mount request information, the method further includes: If the first node does not exist in the mount directory tree, then 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. The at least one node includes the first node. Mount information is created 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 generated the mount request information.

5. The method as described in any one of claims 1 to 3, characterized in that, Before creating at least one node in the mount directory tree based on the mount request information, the method further includes: If a first node exists in the mount directory tree, the reference count in the mount information of the first node is incremented 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. Then, 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 includes: Obtain an uninstallation request message, which carries a file access directory; Unmount the mounted directory associated with the file access directory.

7. The method as described in claim 6, characterized in that, The unloading of the mounted directory associated with the file access directory includes: The mount directory associated with the file access directory is determined as the second directory; Decrement the reference count in the mount information of the third node by 1. The third node is the node in the mount directory tree that contains mount information among all the nodes that constitute the second target. If the reference count in the mount information of the third node is not 0 after being decremented by 1, then the association between the third node in the mount directory tree and the mount directory indicated by the nodes under the third node and the file access directory corresponding to the application that generated the uninstallation request message is cancelled.

8. The method as described in claim 7, characterized in that, After decrementing the reference count in the mount information of the third node by 1, the process also includes: If the reference count in the mount information of the third node is decremented by 1 and becomes 0, then the parent node of the third node, the third node, and all nodes under the third node are deleted from the mount directory tree. The association between the mount directory indicated by the deleted node and the file access directory is canceled. An unmount 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 includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 8.

Images