File sharing method, electronic equipment and computer readable storage medium

Abstract

The invention relates to the technical field of intelligent terminals, in particular to a file sharing method, electronic equipment and a computer readable storage medium. The method comprises the following steps: in response to a first sharing operation that a first electronic device detects that a user indicates to share a first file with a second electronic device, the second electronic device displays the first file; the second electronic equipment stops displaying the first file in response to the fact that the first electronic equipment detects that the first file meets a first condition of ending sharing, and the first condition includes that sharing permission information corresponding to the second electronic equipment cannot be matched, or the matched sharing permission information corresponding to the second electronic equipment is invalid. According to the scheme, in the file sharing process, security management and control can be carried out on the target device to open or acquire the sharing permission information of the target file, it is ensured that the target file can only be accessed or acquired by the specified target device in the non-failure period, and the security of the target file in the sharing process can be improved.

Description

File sharing method, electronic device, and computer-readable storage medium

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on September 26, 2022, with application number 202211176908.9 and application name “Method for sharing files, electronic device and computer-readable storage medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present invention relates to the technical field of intelligent terminals, and in particular to a file sharing method, an electronic device, and a computer-readable storage medium. Background Art

[0003] With the development of smart terminal technology, users have more and more terminal devices, and the number of scenarios in which users relay and collaborate between different terminal devices is increasing. For example, users may play videos received on their mobile phones on their TVs, or process documents received on their mobile phones on their computers.

[0004] Therefore, many smart terminals can form a super terminal through distributed technology. Users also increasingly expect to open documents across devices.

[0005] The experience of copying and pasting files, text and other data is the same as local operation.

[0006] It is hoped that the interface for sharing files across devices can be normalized with the local interface, without the need for special adaptation for different cross-device scenarios.

[0007] However, in the current cross-device file sharing solutions, there is a lack of security control over the target files being shared, which leads to a great threat to the security of the target files during the sharing process.

[0008] Summary of the Invention

[0009] In view of this, embodiments of the present application provide a file sharing method, electronic device, and computer-readable storage medium to improve the security of the target file during file sharing. Specifically, the method includes the following aspects:

[0010] In a first aspect, an embodiment of the present application provides a method for sharing files, the method comprising: in response to a first electronic device detecting a first sharing operation in which a user instructs to share a first file with a second electronic device, the second electronic device displays the first file; in response to the first electronic device detecting that the first file meets a first condition for ending sharing, the second electronic device stops displaying the first file, wherein the first condition includes that sharing permission information corresponding to the second electronic device cannot be matched, or the matching sharing permission information corresponding to the second electronic device has expired.

[0011] That is, the first electronic device can ensure the security of the shared target file during the sharing process based on the preset first condition for controlling the end of sharing. For example, the above-mentioned first electronic device can be a mobile phone, which serves as the local device; the above-mentioned second electronic device can be a computer, which serves as the target device; the above-mentioned first file is, for example, a target file such as a picture or document stored locally on the mobile phone, and the above-mentioned first sharing operation is an operation in which the user instructs the computer to open the target file such as the picture or document on the mobile phone. Based on the solution provided by the above-mentioned first aspect, if the mobile phone detects that the target file such as the picture or document specified by the user to be shared with the computer meets the first condition for ending sharing, for example, when the mobile phone cannot match the authorization information (i.e., the above-mentioned sharing permission information) that authorizes the second electronic device to open the corresponding target file, or when the mobile phone matches the sharing permission information corresponding to the second electronic device but the information has expired, the computer will no longer be able to display the corresponding target file shared by the mobile phone.

[0012] In this way, a target file such as a picture or document shared by a first electronic device (e.g., a mobile phone) can only be displayed by a designated second electronic device (e.g., a computer) while the sharing permission information or authorization information is valid. Other electronic devices or second electronic devices whose authorization information has expired cannot display the corresponding target file. Therefore, the security of the target file during the sharing process can be guaranteed.

[0013] In a possible implementation of the first aspect above, the sharing permission information corresponding to the second electronic device cannot be matched, including that the sharing permission information of the first file for the second electronic device is not set in the first electronic device; the matched sharing permission information corresponding to the second electronic device has expired, including that the sharing permission information of the first file set in the first electronic device for the second electronic device has been deleted.

[0014] For example, if the user does not specify authorization for the second electronic device to open the target file on the first electronic device, the first electronic device will not set the authorization information of the first file (i.e., the target file specified for sharing) to the second electronic device, i.e., the sharing permission information. In this case, the first electronic device cannot match the sharing permission information corresponding to the second electronic device.

[0015] For another example, although the user specifies authorization for the second electronic device to open the target file on the first electronic device, the user does not operate the second electronic device to browse the target file for a long time, or the first electronic device or the second electronic device is disconnected from the network and then reconnected to the network, the first electronic device and the second electronic device will be reconnected, and the authorization information of the first file (i.e., the target file specified for sharing) set in the first electronic device for the second electronic device will be deleted. At this time, the first electronic device detects that the matching sharing permission information corresponding to the second electronic device has expired.

[0016] In a possible implementation of the first aspect, the first electronic device detects that the first file meets the first condition for terminating sharing, including: the first electronic device cannot match the first permission information corresponding to the second electronic device based on at least one sharing permission information corresponding to the first file; or the first electronic device determines that the first permission information has expired based on a first management policy corresponding to the first file, and the method further includes:

[0017] In response to the first electronic device detecting that the user opens the first file on the second electronic device, a prompt interface is displayed on the second electronic device, where the prompt interface is used to prompt that the second electronic device does not have access rights to the first file.

[0018] That is, the first electronic device may include multiple shared permission information authorized to multiple electronic devices in the shared target file, and the first electronic device can perform security management on the corresponding shared permission information through the security management policy corresponding to each electronic device. For example, the first electronic device can determine whether the first permission information corresponding to the second electronic device has expired based on the first management policy set corresponding to the authorization of sharing the first file to the second electronic device. Moreover, when the first electronic device determines that the corresponding permission information has expired based on the security management policy, for example, it determines that the above-mentioned first permission information has expired based on the above-mentioned first management policy, if the first electronic device detects that the second electronic device attempts to open the above-mentioned first file, then the first electronic device no longer shares the target file (i.e., the first file) with the second electronic device at this time. Accordingly, a prompt interface can be displayed on the second electronic device to remind the user that the second electronic device no longer has the right to access the target file on the first electronic device. In this way, the user can be informed of the invalid authorization in a timely manner, so that the user can re-perform the relevant operations of sharing the file when he needs to open the target file across devices.

[0019] In a possible implementation of the first aspect above, the first management and control strategy includes: a timeout expiration strategy, which is used to invalidate the first permission information when it is detected that the first permission information has not been used for more than a preset expiration period; and / or a link disconnection strategy, which is used to invalidate the first permission information when it is detected that the communication connection between the first electronic device and the second electronic device is disconnected.

[0020] In a possible implementation of the first aspect above, the first electronic device determines that the first permission information has expired based on the first management policy corresponding to the first file, including: the first electronic device detects whether the unused time of the first permission information exceeds the preset expiration period, and deletes the first permission information based on the timeout expiration policy; or, the first electronic device detects that the communication connection between the first electronic device and the second electronic device is disconnected, and deletes the first permission information based on the broken link expiration policy.

[0021] For example, the preset expiration time corresponding to the timeout expiration policy can be preset to 2 minutes, that is, the effective time threshold. Furthermore, based on the timeout expiration policy, it is possible to verify whether the time interval between the moment when the target device (such as the second electronic device mentioned above) opens the distributed file this time and the moment when the distributed file record is last closed exceeds 2 minutes. If it exceeds, it can be determined that the authorization information corresponding to the target device, such as the first permission information mentioned above, has expired. For example, the authorization information can be invalidated by deleting the authorization information. If the target device uses the corresponding authorization information to open the corresponding shared target file within the preset expiration time, then based on the above-mentioned timeout expiration policy, it can also be judged that the authorization information corresponding to the target device is valid.

[0022] In a possible implementation of the first aspect above, the first electronic device includes a distributed file system, and the first electronic device detects a first sharing operation in which a user instructs the user to share a first file with a second electronic device, including: the first electronic device creates a first mapping file corresponding to the first file in the distributed file system in response to the first sharing operation, wherein a first mapping relationship exists between the first file and the first mapping file; the first electronic device sets first permission information and a first management policy in the created first mapping file; the first electronic device sends a first sharing request to the second electronic device, wherein the first sharing request includes a global identifier of the first mapping file, and the global identifier is a unique identifier of the first mapping file in the first electronic device.

[0023] The first electronic device, i.e., the local device, can, when detecting an operation in which the user specifies to share a target file, first create a mapping file corresponding to the target file in the distributed file system, such as the above-mentioned first mapping file, and set a security control policy in the created first mapping file, such as the above-mentioned first control policy. Furthermore, the first electronic device can share the content of the target file by sharing the read and write permissions of the first mapping file by sending the global identifier corresponding to the first mapping file to the second electronic device. In this way, during the sharing process of the shared target file, through the sharing capability of the distributed file system, the second electronic device can directly access the first mapping file in the distributed file system based on the corresponding authorization information to read and write the target file, thereby achieving better sharing effect and further improving the security of the target file.

[0024] In a possible implementation of the first aspect above, the global identifier includes a uniform resource identifier URI of the first mapping file, and the second electronic device displays the first file, including: the second electronic device responds to the first sharing request, opens the first file based on the URI of the first mapping file and the first mapping relationship; or, the second electronic device responds to the first sharing request, obtains the first file based on the URI in the first sharing request and the first mapping relationship.

[0025] For example, in a cross-device file opening scenario, the first electronic device can share the URI of the first mapping file corresponding to the target file with the target device specified by the user. The target device can then open the content of the first file on the first electronic device based on the URI of the first mapping file and the mapping relationship between the target file and the first mapping file.

[0026] For another example, in a cross-device copy and paste scenario, the first electronic device can, in response to the user's copy operation, share the first mapping file URI corresponding to the target file with one or more currently connected electronic devices, including the second electronic device. Furthermore, the second electronic device can, in response to the user's paste operation, obtain the memory space of the first file on the first electronic device to the second electronic device based on the first mapping file URI in the first sharing request.

[0027] In a possible implementation of the first aspect above, the first sharing request also includes a first application identifier of the first application, wherein the first application is an application installed on the second electronic device; and the second electronic device displays the first file, including: the second electronic device responds to the first sharing request, based on the URI, the first application identifier and the first mapping relationship in the first sharing request, opens the first file through the first application; or, the second electronic device responds to the first sharing request, based on the URI, the first application identifier and the first mapping relationship in the first sharing request, obtains the first file to the memory space corresponding to the first application.

[0028] In a possible implementation of the first aspect above, the first file and the first mapping file both include a file structure, a dentry structure, and an inode structure, and the first mapping relationship includes: the file structure of the first file is mapped correspondingly to the file structure of the first mapping file, and the dentry structure of the first file is mapped correspondingly to the dentry structure of the first mapping file, and the inode structure of the first file is mapped correspondingly to the inode structure of the first mapping file.

[0029] In a possible implementation of the first aspect above, the first electronic device sets the first permission information and the first control policy in the created first mapping file, including: setting the first permission information and the first control policy in the dentry structure of the first mapping file.

[0030] In a possible implementation of the first aspect above, the first sharing operation includes: an opening operation on the first file, or a copying operation on the first file.

[0031] In a possible implementation of the first aspect, the prompt interface displays a prompt message to prompt that the second electronic device does not have access rights to the first file, wherein the prompt message includes content indicating that the first file does not exist.

[0032] That is, if the first electronic device determines that the authorization information corresponding to the second electronic device accessing the first file has expired or does not exist, when the user operates the second electronic device to try to open or obtain the first file, the second electronic device can display a prompt interface to inform the user, for example, prompting the user that the target file (that is, the above-mentioned first file) does not exist.

[0033] In a second aspect, an embodiment of the present application provides a method for sharing files, which is applied to a first electronic device, and the method includes: detecting a first sharing operation in which a user instructs to share a first file with a second electronic device, and sending a first sharing request to the second electronic device, wherein the first sharing request is used to instruct the second electronic device to display the first file; detecting that the first file meets a first condition for ending sharing, and sending a notification for ending sharing to the second electronic device, wherein the first condition includes that the sharing permission information corresponding to the second electronic device cannot be matched, or the matching sharing permission information corresponding to the second electronic device has expired.

[0034] In a possible implementation of the second aspect above, detecting that the first file meets the first condition for ending sharing includes: failing to match the first permission information corresponding to the second electronic device in at least one sharing permission information corresponding to the first file; or determining that the first permission information has expired based on the first management policy corresponding to the first file, and the above method also includes: detecting the user's opening operation of opening the first file on the second electronic device, and sending a prompt message to the second electronic device, wherein the prompt message is used to instruct the second electronic device to display a prompt interface, and the prompt interface is used to prompt that the second electronic device does not have access rights to the first file.

[0035] In a possible implementation of the second aspect above, the first management and control strategy includes: a timeout expiration strategy, which is used to invalidate the first permission information when it is detected that the first permission information has not been used for more than a preset expiration period; and / or a link disconnection strategy, which is used to invalidate the first permission information when it is detected that the communication connection between the first electronic device and the second electronic device is disconnected.

[0036] In a possible implementation of the second aspect above, the first electronic device includes a distributed file system, and detects a first sharing operation in which a user indicates to share a first file with a second electronic device, including: in response to the first sharing operation, creating a first mapping file corresponding to the first file in the distributed file system, wherein a first mapping relationship exists between the first file and the first mapping file; setting first permission information and a first management policy in the created first mapping file; and sending a first sharing request to the second electronic device, wherein the first sharing request includes a global identifier of the first mapping file, which is a unique identifier of the first mapping file in the first electronic device.

[0037] In a possible implementation of the second aspect above, the first file and the first mapping file both include a file structure, a dentry structure, and an inode structure, and the first mapping relationship includes: the file structure of the first file is mapped correspondingly to the file structure of the first mapping file, and the dentry structure of the first file is mapped correspondingly to the dentry structure of the first mapping file, and the inode structure of the first file is mapped correspondingly to the inode structure of the first mapping file.

[0038] In a possible implementation of the second aspect, setting the first permission information and the first control policy in the created first mapping file includes setting the first permission information and the first control policy in the dentry structure of the first mapping file.

[0039] In a third aspect, an embodiment of the present application provides a method for sharing files, which is applied to a second electronic device, and the method includes: displaying the first file in response to a received first sharing request corresponding to the first file, wherein the first sharing request is a request generated by the first electronic device in response to a first sharing operation of the user, and the first sharing operation is an operation instructing to share the first file with the second electronic device; and stopping displaying the first file in response to a received notification of ending sharing corresponding to the first file, wherein the notification of ending sharing is a notification generated by the first electronic device when it detects that the first file meets a first condition for ending sharing, and the first condition includes that the sharing permission information corresponding to the second electronic device cannot be matched, or the matching sharing permission information corresponding to the second electronic device has expired.

[0040] In a possible implementation of the third aspect above, in response to the received notification of ending sharing of the first file, the method further includes: displaying a prompt interface, wherein the prompt interface is used to prompt that the second electronic device does not have access rights to the first file.

[0041] In a possible implementation of the third aspect above, the first sharing request includes a global identifier of the first mapping file, wherein the first mapping file is a file created by the first electronic device in the distributed file system in response to the first sharing operation, and there is a first mapping relationship between the first mapping file and the first file, and the global identifier is a unique identifier of the first mapping file in the first electronic device.

[0042] In a possible implementation of the third aspect above, the global identifier includes a uniform resource identifier URI of the first mapping file, and in response to a first sharing request corresponding to the first file received, the first file is displayed, including: in response to the first sharing request, based on the URI of the first mapping file and the first mapping relationship, opening the first file; or, in response to the first sharing request, based on the URI in the first sharing request and the first mapping relationship, obtaining the first file.

[0043] In a possible implementation of the third aspect above, the first sharing request also includes a first application identifier of the first application, wherein the first application is an application installed on the second electronic device; and, in response to the received first sharing request corresponding to the first file, the first file is displayed, including: in response to the first sharing request, based on the URI, the first application identifier and the first mapping relationship in the first sharing request, opening the first file through the first application; or, in response to the first sharing request, based on the URI, the first application identifier and the first mapping relationship in the first sharing request, obtaining the first file to the memory space corresponding to the first application.

[0044] In a fourth aspect, an embodiment of the present application provides an electronic device comprising: one or more processors; one or more memories; one or more memories storing one or more programs, which, when one or more programs are executed by one or more processors, enables the electronic device to execute the method for sharing files provided in the above-mentioned first to third aspects, and various possible implementations of the above-mentioned first to third aspects.

[0045] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium having instructions stored thereon. When the instructions are executed on a computer, the computer executes the method for sharing files provided in the first to third aspects and various possible implementations of the first to third aspects.

[0046] In a sixth aspect, an embodiment of the present application provides a computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the method for sharing files provided in the above-mentioned first to third aspects, and various possible implementations of the above-mentioned first to third aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] FIG1 shows a schematic diagram of a sharing scenario.

[0048] Figure 2a shows a method based on iOS TM The operating system's scheme for sharing files.

[0049] FIG2 b shows a solution for sharing files by screen projection.

[0050] FIG3 a is a schematic diagram showing a system interaction for sharing files based on a distributed file system provided in an embodiment of the present application.

[0051] FIG3 b shows an example of establishing a mapping relationship between a distributed file and a target file provided in an embodiment of the present application.

[0052] FIG3 c is a schematic diagram showing the implementation process of a file sharing method provided in an embodiment of the present application applied to a specific scenario.

[0053] FIG4 shows a sharing scenario of opening a target file across devices provided in Example 1 of the present application.

[0054] FIG5 is a flowchart of a method for sharing files provided in Example 1 of the present application.

[0055] FIG6 a is a schematic diagram showing a prompt interface displayed on a target device according to Example 1 of the present application.

[0056] FIG6 b is a schematic diagram showing a prompt interface displayed on another target device provided in Example 1 of the present application.

[0057] FIG7 shows a flowchart of a process for implementing security control over a shared file based on a security control policy, as provided in an embodiment of the present application.

[0058] FIG8 a shows a sharing scenario of copying a target file across devices provided in Example 2 of the present application.

[0059] FIG8b shows another sharing scenario of copying a target file across devices provided in Example 2 of the present application.

[0060] FIG9 is a flowchart of a method for sharing files provided in Example 2 of the present application.

[0061] FIG10 is a schematic diagram showing a distributed file creation process on a mobile phone 100 provided in Example 2 of the present application.

[0062] FIG11 is a schematic diagram of a prompt interface displayed when an acquisition request for a target device is rejected, as provided in Example 2 of the present application.

[0063] FIG12 is a schematic diagram showing the hardware structure of a mobile phone 100 provided in an embodiment of the present application.

[0064] FIG13 is a schematic block diagram of a distributed system architecture provided in an embodiment of the present application. DETAILED DESCRIPTION

[0065] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described in detail below with reference to the accompanying drawings and specific implementation methods.

[0066] It should also be stated that the steps in the methods and processes in the embodiments of the present application are numbered for ease of reference, rather than to limit the order of precedence. If there is a sequence between the steps, the written description shall prevail.

[0067] In order to facilitate those skilled in the art to understand the solutions in the embodiments of the present application, some concepts and terms involved in the embodiments of the present application are explained below.

[0068] (1) Handoff, Apple TM One of the features that enables "continuous communication" across devices. This feature enables continuous work between different devices. As the name suggests, the task that was not completed by the previous device can be relayed to the next device to complete it.

[0069] (2) Distributed File System (DFS) refers to a file system that manages physical storage resources that are not necessarily directly connected to local nodes, but are connected to nodes through a computer network; or a complete hierarchical file system formed by combining several different logical disk partitions or volumes. The nodes can be terminal electronic devices such as mobile phones and computers. DFS provides a logical tree-like file system structure for resources distributed anywhere on the network, making it easier for users to access target files distributed on the network. For example, a mobile phone can access files on a computer under the same system based on a distributed file system, and a computer can also obtain files on a mobile phone under the same system based on a distributed file system.

[0070] Based on a distributed file system, electronic devices located at different nodes can access corresponding files in the distributed file system based on file identifiers or index identifiers. Files accessible by various nodes in a distributed file system are referred to as distributed files. Each distributed file in a distributed file system can be a mapping file corresponding to a local file on the electronic device at each node.

[0071] (3) Uniform Resource Identifier (URI), a computer term, refers to a string of characters used to identify the name of an Internet resource. URI allows users to interact with any resource (including local resources and Internet resources) through a specific protocol. The definition of a URI can be determined by a scheme that includes a specific syntax and related protocols. The Internet resources or local resources mentioned above can include HTML documents, images, video clips, programs, etc.

[0072] It should be noted here that, to avoid confusion, in the embodiments of this application, "sharing a file" refers to the process of sharing a file with other devices, and the shared file is referred to as the "target file" in the embodiments of this application. That is, "sharing" is understood as a verb.

[0073] FIG1 shows an application scenario in which a target file to be shared needs to be read and written across devices according to an embodiment of the present application.

[0074] Referring to the scenario shown in FIG1 , a user may also open and edit an image 101 received on a chat interface displayed on a mobile phone 100 on a personal computer (PC) 200, i.e., operation ① shown in FIG1 . Alternatively, a user may choose to open a Word document 102 received on a chat interface displayed on a mobile phone 100 on a personal computer 200, i.e., operation ② shown in FIG1 , in order to read and write to the Word document 102. Alternatively, a user may need to copy an image or text content on a mobile phone 100 and paste it on a document editing interface displayed on a personal computer 200, and so on.

[0075] Based on the scenario shown in FIG1 above, FIG2a shows a method based on iOS TM The operating system's scheme for sharing files.

[0076] As shown in Figure 2a, on iOS TM In the operating system ecosystem, in order to share files on different electronic devices, you can TM The same Apple ID can be used to log in to iCloud on device 1, device 2, and device 3 of the operating system, and Bluetooth (BT), Wi-Fi, and relay functions must be turned on on device 1, device 2, and device 3. In this way, after the user selects the file or file content to be shared on the interface of an application (APP) 1 running on device 1 and copies it, the file or file content will be copied to the clipboard 1 of device 1 and transferred to the clipboard 2 of device 2 and the clipboard 3 of device 3. When the user relays (Handoff) to device 2 or device 3, the file or file content on the clipboard 2 of device 2 or the clipboard 3 of device 3 can be directly pasted to the specified interface, such as the interface of APP2.

[0077] However, the file sharing solution shown in Figure 2a is limited to iOS TMElectronic devices within the operating system ecosystem may share files, potentially sending the target file to multiple devices under the same account, some of which do not need the file being shared. This can expose important target files to a device's less secure storage space, or expose the target file to leaks or malicious theft because multiple devices can open it. In other words, the file sharing scheme shown in Figure 2a presents significant security risks.

[0078] Based on the scenario shown in FIG1 above, FIG2b shows a solution for sharing files through screen projection.

[0079] As shown in Figure 2b, device A opens a file by running an APP, for example, a video file is opened through a video APP, which is “1. Open file” shown in Figure 2b. Device A can then establish a screen casting connection with the screen casting service B on device B through screen casting service A, which is “2. Screen casting connection” shown in Figure 2b. The control signal generated by the user's operation on the control interface of the APP running on device A can be sent to screen casting service B through screen casting service A. This control signal can be used to control the playback progress of the video file, for example.

[0080] However, the file sharing solution implemented by screen projection shown in FIG2b requires sending the corresponding data stream of the target file to be shared to other terminal devices for playback or display in real time. Therefore, the target file cannot be read, edited, or otherwise operated on the target device. In other words, read and write operations are not possible. The screen projection solution shown in FIG2b is not truly cross-device file sharing and cannot meet the user's operational needs for reading and writing target files across devices. For example, it is not applicable to the application scenario shown in FIG1 above, where a computer application is used to open a picture on a mobile phone for editing.

[0081] In summary, in the application scenario shown in Figure 1 above where the target file to be shared needs to be read and written across devices, the current solution for sharing files across devices lacks security control over the target file, resulting in low security of the target file during the sharing process.

[0082] To address the above issues, embodiments of the present application provide a method for sharing files, which is applied to electronic devices with a distributed file system. The electronic device that provides the target file to be shared is referred to as the local device in this embodiment of the application, and the electronic device that is authorized to perform cross-device read and write operations on the target file is referred to as the target device in this embodiment of the application.

[0083] Specifically, the method creates a distributed file that maps to a local target file to be shared based on the target device information specified by the user when triggering a sharing operation. The method also sets authorization information for the target device and a security control policy corresponding to the distributed file in the created distributed file. The authorization information may include device identification information for the target device, and the sharing operation may include operations such as specifying the target device to open or copy the target file. The security control policy may include a timeout policy and / or a link-break policy. For example, the timeout policy may terminate sharing by disabling authorization for the target device upon detecting that the target device has not performed any read or write operations on the target file within a preset time period. The link-break policy may terminate sharing by deleting authorization information for the target device upon detecting a disconnection from the target device. Furthermore, the target device can open or paste the distributed file across devices based on the distributed file system, as well as perform operations such as read and write operations on the distributed file. During the sharing process, the local device can implement security controls such as timeout and link-break policies on the target device's permissions to operate the distributed file based on the security control policy, thereby improving the security of the target file during sharing. It can be understood that the above corresponding operations can be mapped to the target file mapped corresponding to the distributed file on the local device.

[0084] In this way, the file sharing method provided by the embodiment of the present application fully guarantees the security of the shared target file. This security guarantee includes: first, the distributed file mapped to the target file can only be opened and read and written by the designated shared target device. Other unauthorized devices cannot open the distributed file mapped to the target file and therefore have no right to operate the target file. Second, the process of the target device opening or reading and writing the distributed file mapped to the target file is securely controlled. For example, if the target device does not operate the distributed file mapped to the target file within the valid time, or the communication connection between the target device and the local device is disconnected, the sharing can be terminated in time to ensure the security of the target file.

[0085] It is understood that the communication connection between the above-mentioned local device and the target device can be, for example, a connection method such as Wi-Fi, Bluetooth (BT) or near field communication (NFC), and the local device and the target device can share the distributed files created by the corresponding target files based on a distributed file system. It is understood that the above-mentioned distributed file system can be understood as a file system including the two nodes of the above-mentioned local device and the target device, or it can be understood as a file system that is respectively set in the operating system of the local device and the target device and can communicate with each other, and there is no limitation here. The communication connection between the operating system of the local device and the target device can be, for example, connected through a distributed soft bus.

[0086] FIG3 a shows a schematic diagram of system interaction for sharing files based on a distributed file system according to an embodiment of the present application.

[0087] As shown in Figure 3a, the local device is device A, and the target device is device B. Device A's operating system includes at least Application A installed at the application layer, a distributed sharing service and distributed file system provided at the system service layer, and the target file located in the kernel layer's local storage space. Device B's operating system includes at least Application B installed at the application layer, a distributed sharing service and distributed file system provided at the system service layer. As described above, devices A and B can be nodes of the same distributed file system, and devices A and B can be nodes of the same distributed sharing service.

[0088] It is understood that the file sharing method provided in the embodiment of the present application is applicable to operating systems including distributed sharing services and distributed file systems. The operating systems installed on device A and device B may include but are not limited to Hongmeng TM Operating system (HarmonyOS TM ), Android TM (Android TM ), iOS TM etc., no restriction is made here.

[0089] Among them, the distributed sharing service can provide the local device with the ability to select a remote target device to share a distributed file URI. In addition, the distributed sharing service can use the distributed file system of the local device to map the local target file of the local device to a distributed file and generate a distributed file URI. Furthermore, the local device can share the distributed file URI with the target device based on the distributed sharing service, complete the authorization of the target device to read and write the distributed file, and realize the process of sharing the file. The distributed sharing service can also set the authorization information corresponding to the target device and the security management policy for the corresponding authorization information in the distributed file created to implement security management of the file sharing process.

[0090] Continuing with FIG3a, the user can select the target device to open the shared file on the interface of application A running on device A, i.e., “1. Select the device and application to share” as shown in FIG3a. In the scenario shown in FIG1 above, for example, the user can select the target device to open the shared file on the interface of application A running on device A, i.e., “1. Select the device and application to share” as shown in FIG3a. TM The target device for opening the picture 101 on the chat interface is selected as the computer 200, and you can also choose to use the drawing application on the computer 200 as the application program for opening the picture.

[0091] Furthermore, the distributed sharing service can obtain information about the target device selected by the user, create a virtual distributed file in the distributed file system, and establish a mapping relationship between the locally stored target file and the created distributed file, as shown in "2. Creating a virtual distributed file and establishing a mapping relationship between the target file and the distributed file" in Figure 3a. The target file can, for example, be the file selected by the user when performing a sharing operation on the interface of Application A. This mapping relationship can include a one-to-one mapping relationship between components such as a file structure, a directory entry (dentry) structure, and an inode structure used to locate corresponding data blocks. The file structure, dentry structure, and inode structure of the target file can describe the contents of the target file from three dimensions. The file structure is used to describe the relevant operation interfaces of the target file, including interfaces for opening, reading, and writing the target file. The dentry structure is used to record the relationship between the target file and other directories and files in the corresponding file system, including information about subdirectories and parent directories of the directory where the target file is located. The inode structure is used to record the file size and basic descriptive information.

[0092] That is to say, the mapping relationship between the target file and the above-mentioned components corresponding to the distributed file can be understood as mapping the file structure of the target file to the file structure of the distributed file, mapping the dentry structure of the target file to the dentry structure of the distributed file, and mapping the corresponding inode structure of the target file to the corresponding inode structure of the distributed file.

[0093] FIG3 b shows an example of establishing a mapping relationship between a distributed file and a target file according to an embodiment of the present application.

[0094] As shown in Figure 3b, establishing a mapping relationship between a distributed file and a target file can be achieved by mapping the file structure of the distributed file to the file structure of the target file, mapping the dentry structure of the distributed file to the dentry structure of the target file, and mapping the inode structure of the distributed file to the inode structure of the target file. Optionally, the mapping between the structures of the distributed file and the target file can be performed by constructing a functional relationship or executing some mapping algorithm, etc., which is not limited here.

[0095] In addition, when creating a distributed file, the distributed sharing service in device A can authorize the shared file selected on the interface of application A to be shared with the target device, and the corresponding target device related information obtained can be written into the distributed file as part of the authorization information. For example, the identity identification information (Identity document, ID) of the target device is written into the dentry structure of the distributed file and saved as a private data structure on device A. The target device ID can constitute a part of the authorization information corresponding to the target device. Moreover, the security control policy corresponding to the above-mentioned distributed file setting, such as the above-mentioned timeout expiration policy and / or broken link expiration policy, can also be written into the dentry structure of the distributed file. This can improve the security of shared files during the sharing process.

[0096] After completing the creation of the distributed file and establishing the above-mentioned mapping relationship, device A can generate the URI corresponding to the distributed file through the distributed sharing service and send the distributed file URI to application B on device B, which is shown in Figure 3a as "3. Share the distributed file URI with application B on device B". The distributed file URI can include the resource path corresponding to the distributed file, etc., so that application B can accurately find the distributed file mapped to the target file. After that, application B on device B can find the corresponding distributed file in the distributed file system based on the received distributed file URI and open the distributed file for reading and writing, which is the process of "4. Open the distributed file" shown in Figure 3a.

[0097] With reference to the scenario shown in FIG1 above, FIG3c shows a schematic diagram of an implementation process of a file sharing method applied to a specific scenario according to an embodiment of the present application.

[0098] As shown in FIG3c, device A may be, for example, a mobile phone 100, device B may be, for example, a computer 200, and application 1 running on the mobile phone 100 may be, for example, WeChat. TM Application, the application 2 designated to open the target file on device B can be, for example, a word application. Referring to the system interaction process described in FIG3a above, it can be seen that based on the file sharing method provided in the embodiment of the present application, the user's WeChat on device A TM The interface allows you to select the device and application to share, for example, you can select the word application on device B. The distributed sharing service on device A can create a distributed file in the distributed file system and establish a mapping relationship between the local file and the distributed file. The local file is stored in the local storage space or local file system of device A. The local file can be, for example, the WeChat in the scenario shown in Figure 1 above. TM The word document "XXXX.docx" 102 received on the chat interface is also a target file to be shared.

[0099] Furthermore, the distributed sharing service on device A can share the distributed file URI corresponding to the distributed file created above with the word application on device B, i.e., application 2. The word application can then open the distributed file based on the received distributed file URI and perform read and write operations. It can be understood that the distributed file system applied on device A can use the distributed sandbox mechanism for permission management. For example, it can perform permission verification on the operation request of the word application on device B to open the distributed file, such as verifying the authorization information and whether the authorization information has expired, etc. The details will be described in detail below in conjunction with the corresponding figures.

[0100] It can be understood that in some embodiments, the read and write operations of device B on the distributed file through the distributed file system can eventually be mapped to the target file stored locally on device A. That is, the read and write operations on the distributed file can be equivalent to the read and write operations on the target file mapped by the distributed file. The above-mentioned file mapping method uses distributed files to implement operations such as opening, reading and writing local target files, so that the target file does not need to be sent from the local device to the target device during the file sharing process. Therefore, the shared target file can be stored in the local storage space all the time, which can prevent the target file from being transferred to other electronic devices with lower security, which is conducive to improving the security of the file sharing process.

[0101] It can be understood that the electronic devices to which the file sharing method provided in the embodiments of the present application is applicable may include but are not limited to mobile phones, tablet computers, desktops, laptops, handheld computers, netbooks, as well as augmented reality (AR) and virtual reality (VR) devices, smart TVs, smart watches and other wearable devices, servers, mobile email devices, car devices, portable game consoles, portable music players, reader devices, televisions with one or more processors embedded or coupled thereto, or other electronic devices that can access the Internet.

[0102] The following will combine the scenario shown in Figure 1 above and the implementation process shown in Figure 3, and combine embodiments of different application scenarios to introduce in detail the specific implementation of the method for sharing files provided in the embodiment of the present application.

[0103] The following first introduces the specific implementation process of the method for sharing files provided in the embodiment of the present application in conjunction with the sharing scenario of opening the target file across devices as illustrated in Example 1.

[0104] Example 1

[0105] FIG4 shows a sharing scenario of opening a target file across devices according to the present application.

[0106] As shown in Figure 4, the scenario includes a mobile phone 100 and a computer 200, where the mobile phone 100 and the computer 200 can establish a communication connection, for example, via Wi-Fi, Bluetooth, or a distributed soft bus. The user can select a photo 411 on the camera interface 410 displayed on the mobile phone 100, perform operation ③, and click the share button 412. After that, the mobile phone 100 can display a pop-up window 420. The user can then perform operation ④ in the pop-up window 420 and select the "PC application" opening method, thereby determining that the computer 200 is the target device.

[0107] Furthermore, a pop-up window 430 may be displayed on the camera interface 410 of the mobile phone 100, allowing the user to select an application installed on the computer 200. For example, the user may perform operation ⑤ on the pop-up window 430 and select the "Paint" application to open the photo 411. At this point, the computer 200 may run the paint application, displaying a paint operation interface 450 on the desktop 440. The user may then perform other operations on the photo 411 using the paint operation interface 450 displayed on the computer 200.

[0108] Based on the sharing scenario shown in FIG4 , the specific implementation process of the file sharing method provided in the embodiment of the present application will be described in detail below with reference to the accompanying drawings.

[0109] It should be stated here that the steps in the methods and processes in the embodiments of the present application are numbered for ease of reference, rather than to limit the order of precedence. If there is a sequence between the steps, the written description shall prevail.

[0110] FIG5 shows a flowchart of a method for sharing files according to an embodiment of the present application.

[0111] As shown in Figure 5, the execution entity of each step in the process can be the local device that provides the target file to be shared, such as the mobile phone 100 in the sharing scenario shown in Figure 4. Therefore, in order to simplify the description, the execution entity of each step will not be repeated when introducing the content of each step.

[0112] Specifically, the process includes the following steps:

[0113] 501: A user operation of selecting a target device to open a target file was detected.

[0114] For example, a user can share a target file with a target device on an interface displayed on an electronic device such as a mobile phone 100, and the user can further choose to open the target file using a specified application on the target device. The mobile phone 100 can then detect the corresponding user operation and display the corresponding interface. Referring to the sharing scenario shown in FIG4 above, for example, a user can perform operations ③ to ⑤ on the camera interface 410 displayed on the mobile phone 100 to share a photo 411 with a drawing application on the computer 200. Among them, the photo 411 is the target file, and the computer 200 is the target device.

[0115] It is understood that in the application scenarios of other embodiments, the target device selected corresponding to the user operation detected by the electronic device such as mobile phone 100 can also be another electronic device, and the application selected on the target device to process the target file can also be another application on an electronic device such as computer 200. The target file shared by the user operation can also be a document, video, or other file, without limitation.

[0116] 502: Create a distributed file in the distributed file system based on the target file.

[0117] For example, mobile phone 100 can create a distributed file in the distributed file system based on the content structure of the target file selected for sharing by the user. This creation process can, for example, involve creating the file structure, dentry structure, and inode structure of the distributed file based on the file structure, dentry structure, and inode structure of the target file. The created file structure, dentry structure, and inode structure of the distributed file can be implemented, for example, by copying the file structure, dentry structure, and inode structure of the target file.

[0118] It is understood that the distributed file created in the distributed file system can provide access nodes to the target device based on the sharing capabilities of the distributed file system. The specific process of the target device accessing the distributed file created in the distributed file system will be described in detail in the corresponding steps below and will not be repeated here.

[0119] 503: Set the authorization information and security control policy for the target device in the created distributed file.

[0120] For example, after mobile phone 100 completes the creation of a distributed file, it can write relevant information to the distributed file authorizing the target device to open, read, or write to the distributed file, thereby setting authorization information. This authorization information can be written to the dentry structure of the created distributed file and stored as a private data structure within the dentry structure. In other embodiments, the authorization information can also be written to other structures within the distributed file or to a newly created private data structure, which is not a limitation here.

[0121] Furthermore, the mobile phone 100 may also set a corresponding security control policy in the created distributed file. The security control policy is used to determine certain security restrictions to ensure the security of the distributed file during the operation of reading and writing the distributed file. As previously mentioned, the security control policy may include, for example, a timeout failure policy and / or a broken link failure policy, and may also include other policies that can be used to control the security of the shared file process, which are not limited here.

[0122] The specific implementation process of the mobile phone 100 for security control of the shared file process based on the corresponding timeout failure policy and / or broken link failure policy set in the distributed file will be described in detail below in conjunction with the corresponding drawings and will not be repeated here.

[0123] 504: Establish a mapping relationship between the locally stored target file and the distributed file.

[0124] Exemplarily, the mobile phone 100 can establish a mapping relationship between the distributed file created during the execution of the above step 502, or the distributed file for which authorization information and security management policies are set during the execution of the above step 503, and the locally stored target file. That is, in some embodiments, the mobile phone 100 can execute this step 504 to establish the above mapping relationship after executing the above step 503 to complete setting the authorization information for the target device and the corresponding security management policy in the distributed file. In other embodiments, the mobile phone 100 can also execute this step 504 to establish the above mapping relationship after executing the above step 502 to create the distributed file. This is not limited here. Among them, the process of establishing the mapping relationship between the target file and the distributed file can refer to the above Figure 3b and the related description, and will not be repeated here.

[0125] It is understood that after the mapping relationship between the distributed file and the target file is created, as described above, a security management policy can be set in the distributed file, such as a timeout failure policy and / or a broken link failure policy. It is understood that the module in the system of the mobile phone 100 responsible for managing the communication connection link between the mobile phone 100 and the target device, such as the link management, can record the above mapping relationship and the last access time of the distributed file by the target device.

[0126] In this way, referring to FIG3b above, the mobile phone 100 can achieve triple security based on the security management strategies such as the timeout failure strategy and / or the broken link failure strategy set above: First, it can ensure that the distributed file can only be accessed by the target device. Second, it can ensure that the authorization information for the target device is deleted when the target device is disconnected from the mobile phone 100 as the local device. Third, it can verify the valid time when the target device opens the distributed file, for example, verify whether the time interval corresponding to the current opening and the last closing of the file exceeds the valid time threshold, and update the access time to ensure that the target device can stably access the distributed file within the valid time.

[0127] The specific implementation process of the mobile phone 100 for security control of the shared file process based on the corresponding timeout failure policy and / or broken link failure policy set in the distributed file will be described in detail below in conjunction with the corresponding drawings and will not be repeated here.

[0128] 505: Generate a uniform resource identifier (URI) corresponding to the distributed file.

[0129] Exemplarily, after the mapping relationship between the target file in the mobile phone 100 and the distributed file is created, the mobile phone 100 may further generate a uniform resource identifier for marking the distributed file resource, ie, a distributed file URI.

[0130] As an example, in a distributed file system-based operating system installed on mobile phone 100, a distributed sharing service can initiate a resource call for the distributed file via an Ioctl function to the distributed file system. It is understood that the Ioctl function is a device control interface function in a device driver, which typically implements functions such as opening, closing, reading, and writing to a device. The Ioctl function can trigger the distributed file system to generate the distributed file URI. Therefore, by calling the Ioctl function, the distributed sharing service can obtain the distributed file URI returned by the distributed file system.

[0131] It can be understood that the above-mentioned Ioctl function form of calling a distributed file can refer to Ioctl (dev, fd), for example, wherein the calling parameters (dev, fd) can be resource path parameters of the distributed file, etc., which is not limited here.

[0132] 506: Send the generated distributed file URI to the target device.

[0133] For example, the mobile phone 100 can send the distributed file URI to the target device based on the cross-device sharing capability of the distributed sharing service, for example, to the computer 200 in the sharing scenario shown in Figure 4. In other words, the target device can obtain the distributed file URI shared by the currently connected mobile phone 100 based on the sharing capability of the distributed sharing service.

[0134] It will be appreciated that in some embodiments, the mobile phone 100 can send the distributed file URIs mapped to different target files to multiple currently connected target devices. For example, the mobile phone 100 can send the distributed file URI mapped to a photo file to the computer 200, and send the distributed file URI mapped to a Word document to a home desktop computer. In this way, cross-device file sharing can be achieved between an electronic device such as the mobile phone 100 as a local device and multiple target devices, which is beneficial for improving user operation efficiency and user experience.

[0135] 507: Receive a request for an operation on a distributed file.

[0136] For example, after the mobile phone 100 shares the distributed file URI with the target device, the target device can open the distributed file based on the received distributed file URI to perform read and write operations. The target file content mapped to the distributed file can also be read and written accordingly. In this way, the mobile phone 100 may receive an operation request from the target device requesting to open the target file content or to read and write the target file content. These operation requests can be reflected as operation requests for the distributed file.

[0137] It will be appreciated that in some embodiments, mobile phone 100 can share the URI of a distributed file with multiple target devices, and thus mobile phone 100 may also receive operation requests from multiple target devices. In some embodiments, mobile phone 100 may also receive operation requests from multiple target devices for different distributed files, these operation requests being initiated based on the distributed URI sent by mobile phone 100 in step 506 above. This is not a limitation. In this way, different distributed files can be assigned to different target devices for use. This targeted sharing mechanism helps ensure the security of the target files mapped to each distributed file.

[0138] 508: Based on the authorization information and security control policy, a determination is made as to whether the device currently requesting to operate the distributed file has permission to do so. If so, indicating that the target device has read and write permissions, step 509 is executed to respond to the target device's request to open, read, or write the distributed file. If not, indicating that the target device does not have read and write permissions, step 510 is executed to deny the target device's request to operate the distributed file.

[0139] For example, the mobile phone 100 can verify whether the device currently requesting to open the distributed file has matching authorization information based on the authorization information set in the distributed file, for example, by matching the device ID with the target device ID in the authorization information.

[0140] It is understandable that the device requesting to open a distributed file may be a target device whose permissions have expired. For example, the mobile phone 100 may have deleted the authorization information for the device in the corresponding distributed file. The device requesting to open a distributed file may also be an electronic device run by some malicious program. The malicious program obtains the distributed file URI shared by the mobile phone 100 and other electronic devices, and attempts to open the distributed file to steal data, etc. Therefore, when the mobile phone 100 receives an operation request for a distributed file, it must first verify whether the device that initiates the operation request has the operation permission. In this way, the security of distributed files shared across devices can be improved, and accordingly, the security of the target file mapped to the distributed file is also improved, and the security of the file sharing process is also improved.

[0141] It can be understood that in the process of sharing files, the mobile phone 100 can manage the created distributed files based on the set security management and control policies. For example, based on the timeout expiration policy, it can be verified whether the time interval between the moment when the target device opens the distributed file this time and the moment when the distributed file record is last closed exceeds the valid time threshold. If it exceeds, it is determined that the preset conditions for ending authorization are met; if it does not exceed, it is not met. The above-mentioned valid time threshold can be, for example, 2 minutes or other values, which are not limited here. In addition, the mobile phone 100 can promptly update the access time corresponding to the distributed file opened this time. In other embodiments, the mobile phone 100 can also determine whether the preset conditions for ending authorization are met by verifying whether other time intervals exceed the preset valid time threshold.

[0142] For another example, for a broken link failure strategy, when it is detected that the target device is disconnected from the local device, it can be determined that the preset conditions for terminating authorization have been met, and then the authorization for the target device can be terminated, such as by deleting the authorization information for the target device. At this time, the device currently requesting to operate the distributed file does not have the operation permission.

[0143] It is understood that in some embodiments, the mobile phone 100 may share the distributed file URI mapped to the same target file with different target devices. In this case, if a target device meets the preset conditions for terminating authorization, the mobile phone 100 can only delete the authorization information set in the distributed file for that target device, while the authorization information corresponding to other target devices will continue to be retained. When the authorization information corresponding to multiple authorized target devices in the distributed file is completely deleted, the mobile phone 100 can delete the corresponding distributed file.

[0144] The specific implementation process of security control of the shared file process based on the security control strategy will be described in detail below with reference to the accompanying drawings and will not be repeated here.

[0145] 509: In response to the received operation request, perform relevant operations on the distributed file, and complete relevant operations on the target file based on the mapping relationship.

[0146] For example, if the mobile phone 100 verifies that the target device currently operating the distributed file has the operation permission, it can respond to the target device's operation request for the corresponding distributed file, allowing the target device to open the distributed file, and perform operations such as turning pages, modifying, and deleting the content of the opened distributed file, that is, the above-mentioned read and write operations.

[0147] It can be understood that the related operations on the distributed files will be converted into operations on the local target files of the mobile phone 100 based on the mapping relationship, so the corresponding target file content can also be modified accordingly by operations such as reading and writing.

[0148] 510: The target device's request to operate on the distributed file is denied.

[0149] For example, if the mobile phone 100 verifies that the target device currently operating the distributed file does not have the operation permission, the target device's operation request for the distributed file can be rejected, and the sharing ends. At this time, a corresponding prompt message can be displayed on the display interface of the mobile phone 100 as the local device or the target device to indicate that the sharing has ended or to prompt the user for the next operation, etc.

[0150] Based on the sharing scenario shown in FIG. 4 above, FIG. 6 a shows a schematic diagram of a prompt interface displayed on a target device according to an embodiment of the present application.

[0151] During the process of sharing the photo 411, if the mobile phone 100 determines that the computer 200 no longer has the permission to open the photo 411 when executing the above step 508, for example, the time period in which no operation was performed on the shared photo 411 before the computer 200 currently opened the photo 411 has timed out, or the communication connection between the mobile phone 100 and the computer 200 was disconnected during the sharing period, then the mobile phone 100 may reject the computer 200's request to open the photo 411. At this time, as shown in FIG6 a , a prompt window 620 may be displayed on the desktop 610 of the computer 200. The content displayed in the prompt window 620 may be, for example, "The picture no longer exists. The picture may have been renamed, moved, cleaned up, or deleted by other programs.", to prompt the user that the computer 200 currently used no longer has the permission to open the photo shared by the mobile phone 100, or to prompt the user that the sharing has ended.

[0152] In other embodiments, the prompt content displayed in the prompt window 620 may also be other content, which is not limited here.

[0153] FIG6 b shows a schematic diagram of another prompt interface displayed on a target device according to an embodiment of the present application.

[0154] As shown in Figure 6b, in other embodiments, for example, a shared communication connection for other files is established between the mobile phone 300 and the mobile phone 100, but the mobile phone 300 wants to open the photo 411 on the mobile phone 100. In this case, when the mobile phone 100 executes the above step 508, it can be determined that the authorization information of the distributed file corresponding to the photo 411 does not include the mobile phone 300, so it can be determined that the mobile phone 300 does not have the authority to access the photo 411, and the opening operation request of the mobile phone 300 can be rejected. At this time, the mobile phone 300 can display the prompt pop-up window 630 shown in Figure 6b. The prompt pop-up window 630 can also display the prompt content "The picture no longer exists. The picture may have been renamed, moved, cleaned or deleted by other programs." Or other content, which is not limited here.

[0155] In other embodiments, when the target device loses the operating authority for the distributed file or has no authority, the interface of the target device may also be different from the prompt interface shown in FIG. 6a or FIG. 6b above, or the mobile phone 100 as the local device may also display a corresponding prompt interface, which is not limited here.

[0156] It is understood that after the target device loses the operation permission, if the user needs to open the target file across devices again or perform operations such as reading and writing the target file, the user can select the target device again to open the target file on the mobile phone 100. The mobile phone 100 can then re-execute the file sharing process described in steps 501 to 510 in response to the user operation.

[0157] The following describes in detail the specific implementation process of the mobile phone 100 performing security control on the process of sharing files based on the corresponding security control policy set in the distributed file in the above step 508 with reference to the accompanying drawings.

[0158] FIG7 shows a flowchart of a method for implementing security control over a shared file based on a security control policy according to an embodiment of the present application. It is understood that the execution entity of the process shown in FIG7 is also the mobile phone 100. To simplify the description, the execution entity of each step will not be repeatedly described when the specific execution content of each step is introduced below.

[0159] As shown in Figure 7, the process includes the following steps:

[0160] 701: Receive an operation request for a distributed file.

[0161] The execution content of this step 701 is the same as that of the above step 507. Executing this step 701 is equivalent to executing the above step 507. The specific process of responding to the operation request can refer to the relevant description of the above step 507 and will not be repeated here.

[0162] As described above, after executing step 507 and receiving the operation request, the mobile phone 100 can determine whether the requesting device corresponding to the operation request has the operation permission for the distributed file based on the authorization information and security management policy, that is, execute the judgment process of step 508. This judgment process is specifically embodied in the following steps 702 to 704.

[0163] 702: Determine whether the requested distributed file exists. If yes, proceed to step 703 to determine whether a link is broken during the sharing process; if no, proceed to step 706 to reject the operation request.

[0164] For example, based on the received operation request, the mobile phone 100 can first determine whether the corresponding distributed file in the distributed file system still exists. It can be understood that in the process of sharing files, the preset security control policy may cause the distributed file itself to be deleted, or cause the authorization information for a target device in the distributed file to be deleted. For example, based on the preset security control policy interruption chain failure policy, the authorization information for the corresponding target device in the distributed file can be deleted when the communication connection between the mobile phone 100 and the target device is disconnected. When the authorization information of all target devices recorded in the corresponding distributed file is deleted, the distributed file may also be deleted.

[0165] 703: Determine whether the sharing time recorded in the distributed file is earlier than the time when the communication connection with the target device was established. If so, it indicates that the communication connection between mobile phone 100 and the target device was disconnected during the file sharing process. The shared distributed file and the corresponding mapped target file may pose a security risk. Therefore, the following step 706 can be executed to reject the operation request. If not, it indicates that the link was not disconnected during the file sharing process. The shared distributed file and the corresponding mapped target file are both safe. Then, the following step 704 can be executed to further determine the expiration time.

[0166] Exemplarily, when the mobile phone 100 shares the distributed file URI with the target device, it can record this moment as the sharing time. The recorded sharing time can be used as the starting time of the timeout expiration policy in the security management policy preset on the mobile phone 100. In addition, when the mobile phone 100 establishes a communication connection with the target device, the link establishment time can be recorded. Therefore, before the mobile phone 100 makes a judgment based on the timeout expiration policy, it can first compare the sharing time judgment with the link establishment time of the target device. If the link establishment time between the mobile phone 100 and the target device is earlier than the above-mentioned sharing time, that is, the two have established a communication connection before the process of sharing the file begins, it indicates that there is no link break during the process of sharing the file, and the shared distributed file and the corresponding mapped target file are safe. In this case, the following step 704 can be continued to further determine the expiration time of the authorization information.

[0167] If the sharing time recorded when mobile phone 100 shares the distributed file URI is earlier than the link creation time, it indicates that the communication connection between mobile phone 100 and the target device was disconnected during the file sharing process, and the shared distributed file and the corresponding mapped target file may pose a security risk. In this case, the following step 706 must be executed to reject the operation request of the target device.

[0168] 704: Determine whether the authorization information corresponding to the target device has exceeded the expiration time specified by the preset timeout policy. If the determination result is yes, i.e., the authorization information has expired, step 706 is executed to reject the received operation request. If the determination result is no, i.e., the authorization information has not expired, indicating that the target device still has permission to open, read, or write the distributed file, step 705 is executed to respond to the received operation request.

[0169] Exemplarily, the mobile phone 100 can determine the validity period of the authorization information for the target device based on the timeout expiration policy in the security management and control policy preset in the distributed file. The validity period can be, for example, a reasonable preset period such as 2 minutes, 3 minutes, 4 minutes or 5 minutes. Based on the validity period, the expiration time of the authorization information can be determined according to the start time of the most recent update. If the mobile phone 100 determines that the time difference between the start time and the time when the operation request is currently received exceeds the above-mentioned expiration time, it indicates that the authorization information corresponding to the target device has expired, and step 706 can be executed. If the mobile phone 100 determines that the time difference between the time when the operation request is currently received and the start time does not exceed the above-mentioned expiration time, it indicates that the authorization information has not expired, and the following step 705 can be executed.

[0170] It can be understood that the above start time can be, for example, the sharing time of the record corresponding to the shared distributed file URI, or the time when the distributed file is closed, or the time after a certain period of time without any read or write operations, etc., and there is no limitation here.

[0171] It is understood that when the target device opens the distributed file for reading or writing, the timeout policy may not take effect. However, when the target device closes the distributed file, or detects that the target device has not performed any read or write operations on the distributed file for a certain period of time, the shared time recorded above can be updated based on the time when the distributed file was closed or the time after no read or write operations for a certain period of time, and used as the starting time of the timeout policy.

[0172] For the process of obtaining the corresponding time when the target device closes the distributed file, or the corresponding time when the target device opens the distributed file, you can refer to the following example. When the target device opens the distributed file, the relevant preset parameters of the application process that opens the distributed file can be modified in the target device. For example, the count value corresponding to the timeout expiration policy setting in the corresponding application process can be modified. For example, the corresponding count value can be set from "0" to "1", that is, plus one. When the target device closes the distributed file, the mobile phone 100 can set the corresponding count value from "1" to "0". Based on the sharing capability of the distributed sharing service, the mobile phone 100 can obtain the above-mentioned count value corresponding to the update in the target device and determine whether the target device currently opens the distributed file. If the count value obtained by the mobile phone 100 is "1", it is determined that the target device closes the distributed file, and the expiration time in the distributed file can be the expiration time corresponding to the authorization information of the target device, or the expiration time corresponding to the distributed file. There is no limitation here.

[0173] 705: In response to the received operation request, perform relevant operations on the distributed file, and complete relevant operations on the target file based on the mapping relationship.

[0174] The execution content of this step 705 is the same as that of the above step 509. Executing this step 705 is equivalent to executing the above step 509. The specific process of responding to the operation request can refer to the relevant description of the above step 509 and will not be repeated here.

[0175] 706: The target device's request to operate on the distributed file is denied.

[0176] The execution content of this step 706 is the same as that of the above step 510. Executing this step 706 is equivalent to executing the above step 510. The specific process of responding to the operation request can refer to the relevant description of the above step 510 and will not be repeated here.

[0177] In conjunction with the implementation process of each step of the flowchart shown in Figures 5 and 7 above, it can be understood that in the process of sharing a target file across devices, when the mobile phone 100 or other electronic device detects that the user has selected a target device to open the file, it can create a distributed file mapped to the target device to complete the sharing. In addition, based on the above-mentioned file sharing solution provided by the embodiment of the present application, the mobile phone 100 can control the permissions of the target device to open the distributed file and read and write the distributed file based on the authorization information and security management policy pre-set for the target device in the distributed file, thereby effectively improving the security of the target file mapped to the distributed file during the sharing process.

[0178] The following first introduces the specific implementation process of the method for sharing files provided in the embodiment of the present application in conjunction with the application scenario of copying target files across devices as illustrated in Example 1.

[0179] Example 2

[0180] FIG8 a shows a sharing scenario of copying a target file across devices according to an embodiment of the present application.

[0181] As shown in FIG8a , in this scenario, the mobile phone 100 and the computer 200 can establish a communication connection, for example, via Wi-Fi, Bluetooth, or a distributed soft bus. The user can copy an image on the image browsing interface 810 of the mobile phone 100 and then paste the image on the memo interface 820 opened on the computer 200.

[0182] It is understood that in this scenario, when the user does not specify a target device when copying an image on the mobile phone 100, the mobile phone 100 defaults to sharing the user-selected image file with one or more electronic devices currently connected to the mobile phone 100. For example, the electronic device can be a device connected to the mobile phone 100 via a distributed soft bus or a device connected to the mobile phone 100 via Bluetooth, etc., without limitation. However, this sharing process does not send the image file to all devices. Instead, each device connected to the mobile phone 100 can obtain the image file and paste it based on the authorization information and the distributed file URI mapped to the image file. The specific sharing process will be described in detail below in conjunction with the accompanying drawings and will not be repeated here.

[0183] Therefore, each electronic device currently connected to the mobile phone 100 can obtain the image copied on the mobile phone 100 and paste the copied image to the interface specified by the user. For example, the computer 200 can paste the image copied by the user in the mobile phone 100 on the memo interface 820 in response to the user's operation.

[0184] FIG8 b shows another sharing scenario of copying a target file across devices according to an embodiment of the present application.

[0185] As shown in FIG8b , the user can select a Word document 831 to be shared on the document management interface 830 displayed on the mobile phone 100. Then, the user can click the copy button 832 on the interface 830 to perform operation ⑥ shown in FIG8b , completing the process of “1. Select file, copy” shown in FIG8b .

[0186] Continuing with Figure 8b , after the user completes the copy operation, mobile phone 100 may display a selection interface 840 , which allows users to select a target device to copy Word document 831 to. The user can then select a target device on selection interface 840 , such as computer 200 , and perform operation ⑦ shown in Figure 8b . This will copy Word document 831 to the clipboard of computer 200 . Continuing with Figure 8b , the user can then right-click on the desktop 850 of computer 200 and select "Paste" 851 to paste the copied Word document 831 onto the desktop 850 .

[0187] It is understood that in this scenario, when the user copies the image on mobile phone 100, they specify the target device, such as computer 200. Therefore, the Word document can be pasted locally on computer 200. Specifically, computer 200 also obtains the Word document for pasting based on the authorization information and the distributed file URI mapped to the Word document. The specific sharing process will be described in detail below with reference to the accompanying drawings and will not be elaborated here.

[0188] Based on the sharing scenarios shown in FIG. 8 a to FIG. 8 b above, the method for sharing files provided by an embodiment of the present application is described in detail below in conjunction with a flowchart, and the specific implementation process in the sharing scenario of copying target files across devices.

[0189] FIG9 shows a flowchart of another method for sharing files according to an embodiment of the present application.

[0190] As shown in Figure 9, the execution entity of each step in the process can be the local device that provides the target file, such as the mobile phone 100 in the scenario shown in Figures 8a and 8b above. Therefore, in order to simplify the description, when introducing the content of each step below, the execution entity of each step will not be repeated.

[0191] Specifically, the process includes the following steps:

[0192] 901: A user operation of copying a target file is detected, wherein the user operation may or may not specify a target device.

[0193] Exemplarily, the operation of copying a target file on the mobile phone 100 can refer to the corresponding operations in the scenarios shown in Figures 8a to 8b above. Referring to Figure 7 above, when the user operates to copy an image on the image browsing interface 710 of the mobile phone 100, he or she may not specify which device to copy to, that is, not specify a target device. At this time, the mobile phone 100 can record the relevant information that the copy operation does not specify a target device, for example, it can add a corresponding mark. Referring to the scenario shown in Figure 8b above, when the user operates to copy a word document on the document management interface 810 of the mobile phone 100, he or she may specify to copy to a specific device, that is, specify a target device. At this time, the mobile phone 100 can record the relevant information that the copy operation specifies the target device. There is no restriction here.

[0194] 902: Create a distributed file in the distributed file system based on the target file.

[0195] The execution process of this step 902 is the same as that of step 502 in the above embodiment 1. For details, please refer to the relevant description of the above step 502, which will not be repeated here.

[0196] 903: Based on whether the detected user operation of copying the target file specifies a target device, authorization information and a security management policy for the target device are set in the created distributed file.

[0197] For example, if the user operation does not specify a target device, the mobile phone 100 can set authorization information for all currently connected devices in the distributed file. These devices can include, for example, the computer 200 and other electronic devices in the scenario shown in Figure 8a above. In this case, the security control policy set by the mobile phone 100 in the distributed file can be a policy for controlling whether the corresponding authorization information of all currently connected devices is invalid.

[0198] If the user specifies a target device, mobile phone 100 can set authorization information for the target device specified by the user in the distributed file. This target device can be, for example, computer 200 in the scenario shown in Figure 8b above. In this case, the security control policy set by mobile phone 100 in the distributed file can be a policy for controlling whether the authorization information corresponding to the target device expires.

[0199] The specific process of setting the authorization information and the corresponding security management and control policy can refer to the relevant description in step 503 of the above embodiment 1, which will not be repeated here.

[0200] 904: Establish a mapping relationship between the locally stored target file and the distributed file.

[0201] It can be understood that at this point, the mobile phone 100 can complete the process of creating the distributed file mapped to the target file specified by the user for copying.

[0202] FIG10 shows a schematic diagram of a distributed file creation process completed on a mobile phone 100 according to an embodiment of the present application.

[0203] Referring to the left figure in FIG10 , taking the word document “1.docx” in the “docx” format as an example, in response to the user’s copy operation, the mobile phone 100 can create a distributed file “1.docx” in the subdirectory “Shared” under the distributed file system directory “distributed file” based on “1.docx” under the local file system directory “files”. In addition, the mobile phone 100 can complete the mapping between “1.docx” under “files” and “1.docx” under “Shared” in the distributed file system. That is, the mobile phone 100 executes the above steps 902 to 904 to create a distributed file and complete the mapping process between the distributed file and the target file. At this point, referring to the right figure in FIG10 , the mobile phone 100 can create a distributed file “1.docx” in the subdirectory “Shared” under the distributed file system directory “distributed file” and generate a URI corresponding to the distributed file for sharing.

[0204] 905: Generate a uniform resource identifier (URI) corresponding to the distributed file.

[0205] The execution process of this step 905 is the same as that of step 505 in the above embodiment 1. For details, please refer to the relevant description of the above step 505, which will not be repeated here.

[0206] 906 : Based on whether the detected user operation of copying the target file specifies a target device, share the generated distributed file URI.

[0207] For example, if the user operation does not specify a target device, the mobile phone 100 can send the generated distributed file URI to all currently connected devices. Such all devices may include, for example, the computer 200 and other electronic devices in the scenario shown in FIG8a above. If the user operation specifies a target device, the mobile phone 100 can send the generated distributed file URI to the target device specified by the user operation. Referring to the scenario shown in FIG8b above, for example, the mobile phone 100 can send the generated distributed file URI to the computer 200 specified by the user operation.

[0208] The mobile phone 100 can share the distributed file URI to the currently connected device or the target device specified by the user based on the distributed sharing service in the system. The specific sharing process can refer to the relevant description in step 506 of the above embodiment 1, which will not be repeated here.

[0209] 907: Receive a request to obtain a distributed file.

[0210] For example, after the mobile phone 100 shares the distributed file URI with all currently connected devices or the target device specified by the user, the user can perform a paste operation on the target device. At this time, the target device can request to obtain the corresponding distributed file to the local storage space of the target device based on the received distributed file URI. Referring to the creation process shown in Figure 10 above, the distributed file "1.docx" created based on "1.docx" under the "files" directory of the local file system of the mobile phone 100 can be obtained by the target device, such as computer 200, to the local storage space of computer 200 to implement the process of pasting to the desktop or other folders specified by the user, which is not limited here.

[0211] 908: Based on the authorization information and security control policy, determine whether the device currently requesting to operate the distributed file has access permission. If the determination result is yes, indicating that the target device has access permission, then execute step 909 to respond to the target device's request to obtain the distributed file. If the determination result is no, indicating that the target device does not have access permission, execute step 910 to deny the target device's request to obtain the distributed file.

[0212] For example, the mobile phone 100 may verify whether the device currently requesting to open the distributed file has matching authorization information based on the authorization information set in the distributed file.

[0213] It can be understood that in the scenario of unspecified target devices as illustrated in FIG8a above, if some electronic devices do not detect the user operation of pasting the target file within the preset expiration time corresponding to the security control policy, the mobile phone 100 can delete the authorization information corresponding to these electronic devices based on the security control policy. After deleting the authorization information, these electronic devices can no longer obtain the corresponding distributed file based on the distributed file URI to implement the pasting process during this sharing process. Similarly, in the scenario of specified target devices as illustrated in FIG8b above, if the user's paste operation is not detected on the target device for a long time, the authorization information corresponding to the target device will also become invalid.

[0214] The specific process of determining whether the target device has the authority to obtain the distributed file based on the security management policy and authorization information can refer to the relevant description in step 508 of the above embodiment 1, which will not be repeated here.

[0215] 909: In response to the received acquisition request, provide the corresponding distributed file.

[0216] For example, in response to the user's paste operation, the target device can access the distributed file system of the mobile phone 100 based on the received distributed file URI and request that the corresponding distributed file be retrieved to the local storage space of the target device to complete the pasting process. Accordingly, based on the acquisition request of the target device, the mobile phone 100 can paste the distributed file into the distributed file system corresponding to the target device through the sharing capability of the distributed file system. In other embodiments, the process of providing the corresponding distributed file by the mobile phone 100 in response to the target device's acquisition request for the distributed file can also be other, which is not limited here.

[0217] It can be understood that the distributed file requested by the target file can be equivalent to the target file, and the content of the target file will also be shared with the target device accordingly during the above-mentioned pasting process.

[0218] 910: The target device's request to obtain the distributed file is denied.

[0219] For example, if the mobile phone 100 verifies that the target device currently requesting to obtain the distributed file does not have the access authority, the target device's request to obtain the distributed file can be rejected. At this time, the mobile phone 100 as the local device or the display interface of the target device can display a corresponding prompt message.

[0220] Based on the sharing scenario shown in FIG8b above, FIG11 shows a schematic diagram of a prompt interface displayed corresponding to when an acquisition request of a target device is rejected according to an embodiment of the present application.

[0221] When the target device's request to obtain the corresponding distributed file is rejected, it indicates that the mobile phone 100 determines that the target device currently obtaining the distributed file has no authority when executing the above step 908, or the historical authorization information has expired, that is, the target device has lost the operation authority. At this time, as shown in Figure 11, when the user clicks the right button of the mouse on the desktop 1101 of the computer 200 serving as the target device and the operation window 1102 pops up, the "Paste" option 1103 in the operation window 1102 can be displayed as an unselectable state, for example, displayed as a lighter gray, to indicate that the paste operation cannot be performed at this time. Continuing to refer to Figure 11, the corresponding "Paste Shortcut" option in the operation window 1102 can also be displayed as an unselectable state.

[0222] In other embodiments, when the target device loses the operating authority for the distributed file or has no authority, the interface of the target device may also display a prompt interface of other styles different from that shown in FIG. 11 above, or a corresponding prompt interface may also be displayed on the mobile phone 100 serving as the local device, without limitation here.

[0223] It is understood that after the target device loses the operation permission, if the user needs to copy the target file or the target file content on the local device again and paste it to the target device, the user can perform the copy operation again on the mobile phone 100 and complete the paste operation within the preset safe and effective time period. In other words, the mobile phone 100 executes the specific implementation process of cross-device file copying as illustrated in steps 901 to 910 above.

[0224] In conjunction with the implementation process of each step of the flowchart shown in FIG9 , it can be understood that in the process of sharing a target file across devices, the mobile phone 100 or other electronic device can create a distributed file mapped to the target device when detecting the user's copy operation, and determine whether the URI corresponding to the distributed file needs to be shared with all connected electronic devices such as the computer 200, or only share the distributed file URI with the target device specified by the user (such as the computer 200). In addition, based on the above-mentioned file sharing solution provided by the embodiment of the present application, the mobile phone 100 can perform security management on the target device's access to the distributed file to the local storage space based on the authorization information and security management policy corresponding to each connected electronic device or the target device specified by the user for pasting, which are pre-set in the distributed file, thereby effectively improving the security of the target file mapped to the distributed file during the sharing process.

[0225] After introducing the specific implementation process of the file sharing method provided in the above-mentioned embodiment 1 and embodiment 2, the structure that the mobile phone 100 as the local device may have is exemplarily introduced below with reference to the accompanying drawings.

[0226] FIG12 shows a schematic diagram of the hardware structure of a mobile phone 100 according to an embodiment of the present application.

[0227] The mobile phone 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. 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, etc.

[0228] It should be understood that the illustrated structure of the embodiment of the present invention does not constitute a specific limitation on the mobile phone 100. In other embodiments of the present application, the mobile phone 100 may include more or fewer components than shown, or some components may be combined or separated, or arranged differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0229] 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 processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0230] The controller can generate an operation control signal based on the instruction opcode and timing signal to complete the control of instruction fetching and execution. In the embodiments provided in the present application, the processor 110 of the mobile phone 100 can be controlled by the controller to execute the instructions corresponding to the content executed in each step of the process shown in Figure 5 and / or Figure 9 above, so as to implement the file sharing method provided in some embodiments of the present application.

[0231] Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

[0232] In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an Inter-Integrated Circuit (I2C) interface, an Inter-Integrated Circuit Sound (I2S) interface, a Pulse Code Modulation (PCM) interface, a Universal Asynchronous Receiver / Transmitter (UART) interface, a Mobile Industry Processor Interface (MIPI), a General-Purpose Input / Output (GPIO) interface, a Subscriber Identity Module (SIM) interface, and / or a Universal Serial Bus (USB) interface.

[0233] The UART interface is a universal serial data bus used for asynchronous communication. This bus can be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, the UART interface is typically used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 via the UART interface to implement Bluetooth functionality.

[0234] The USB interface 130 is an interface that complies with USB standards and may be a Mini USB interface, a Micro USB interface, a USB Type-C interface, or the like. The USB interface 130 can be used to connect a charger to charge the mobile phone 100 and to transfer data between the mobile phone 100 and peripheral devices. It can also be used to connect headphones to play audio. This interface can also be used to connect other electronic devices, such as augmented reality devices.

[0235] It is understood that the interface connection relationship between the modules illustrated in the embodiment of the present invention is merely an illustrative illustration and does not constitute a structural limitation on the mobile phone 100. In other embodiments of the present application, the mobile phone 100 may also adopt a different interface connection method from the above embodiment, or a combination of multiple interface connection methods.

[0236] The charging management module 140 is configured to receive charging input from a charger. The power management module 141 is configured 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 to power the processor 110, the internal memory 121, the display 194, the camera 193, and the wireless communication module 160.

[0237] The wireless communication function of the mobile phone 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.

[0238] Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in mobile phone 100 can be used to cover a single or multiple 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 other embodiments, the antennas can be used in conjunction with a tuning switch.

[0239] The mobile communication module 150 can provide wireless communication solutions including 2G / 3G / 4G / 5G applied on the mobile phone 100.

[0240] The wireless communication module 160 can provide wireless communication solutions applied to the mobile phone 100, including Wireless Local Area Networks (WLAN) (such as Wireless Fidelity (Wi-Fi) network), Bluetooth, Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication Technology (NFC), Infrared Technology (IR), etc. 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, frequency modulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 110. The wireless communication module 160 can also receive the signal to be sent from the processor 110, frequency modulate it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2. In an embodiment of the present application, the wireless communication solution provided by the wireless communication module 160 can also include a solution for realizing communication connection between devices based on a distributed soft bus.

[0241] In some embodiments, the antenna 1 of the mobile phone 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the mobile phone 100 can communicate with the network and other devices through wireless communication technologies. The above-mentioned wireless communication technologies may include Global System for Mobile communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology. The above-mentioned GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou navigation Satellite system (BDS), the Quasi-Zenith Satellite System (QZSS) and / or the Satellite Based Augmentation System (SBAS).

[0242] Mobile phone 100 implements display functionality through a GPU, display screen 194, and an application processor. The GPU is a microprocessor for image processing that connects display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or modify display information.

[0243] The mobile phone 100 can implement a shooting function through an ISP, a camera 193, a video codec, a GPU, a display 194, and an application processor. The ISP is used to process data fed back by the camera 193. The camera 193 is used to capture still images or videos.

[0244] 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 mobile phone 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement data storage functions. For example, files such as music and videos can be stored on the external memory card.

[0245] The internal memory 121 can be used to store computer executable program code, which includes instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area can 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 can store data created during the use of the mobile phone 100 (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 memory (Universal Flash Storage, UFS), etc. The processor 110 executes various functional applications and data processing of the mobile phone 100 by running instructions stored in the internal memory 121 and / or instructions stored in a memory provided in the processor.

[0246] The mobile phone 100 can implement audio functions such as music playback and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D, and the application processor.

[0247] 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 provided in the processor 110, or some functional modules of the audio module 170 can be provided in the processor 110.

[0248] The speaker 170A, also called a "horn," is used to convert audio electrical signals into sound signals. The mobile phone 100 can listen to music or make hands-free calls through the speaker 170A.

[0249] The receiver 170B, also called the "earpiece", is used to convert audio electrical signals into sound signals. When the mobile phone 100 receives a call or a voice message, the voice can be heard by placing the receiver 170B close to the ear.

[0250] Microphone 170C, also known as "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or sending a voice message, the user can speak by putting their mouth close to the microphone 170C to input the sound signal into the microphone 170C. The mobile phone 100 can be provided with at least one microphone 170C. In other embodiments, the mobile phone 100 can be provided with two microphones 170C, which can not only collect sound signals but also realize noise reduction function. In other embodiments, the mobile phone 100 can also be provided with three, four or more microphones 170C to realize sound signal collection, noise reduction, and identification of sound sources, and realize directional recording function, etc.

[0251] The headphone jack 170D is used to connect a wired headphone and can be a USB interface 130 or a 3.5mm Open Mobile Terminal Platform (OMTP) standard interface or a Cellular Telecommunications Industry Association of the USA (CTIA) standard interface.

[0252] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 180A can be located on display screen 194. There are many types of pressure sensors 180A, such as resistive, inductive, and capacitive. A capacitive pressure sensor can include at least two parallel plates made of conductive material. When force is applied to pressure sensor 180A, the capacitance between the electrodes changes. Mobile phone 100 determines the intensity of the pressure based on this change in capacitance. When a touch operation is applied to display screen 194, mobile phone 100 detects the intensity of the touch operation using pressure sensor 180A. Mobile phone 100 can also calculate the location of the touch based on the detection signal from pressure sensor 180A. In some embodiments, touch operations applied to the same touch location but with different touch intensities can correspond to different operation instructions. For example, when a touch operation with an intensity less than a first pressure threshold is applied to a short message application icon, a command to view short messages is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to a short message application icon, a command to create a new short message is executed.

[0253] The gyroscope sensor 180B can be used to determine the motion posture of the mobile phone 100. In some embodiments, the angular velocity of the mobile phone 100 around three axes (i.e., x, y, and z axes) can be determined by the gyroscope sensor 180B. The gyroscope sensor 180B can be used for anti-shake shooting. For example, when the shutter is pressed, the gyroscope sensor 180B detects the angle of the mobile phone 100 shaking, calculates the distance that the lens module needs to compensate based on the angle, and allows the lens to offset the shaking of the mobile phone 100 through reverse movement to achieve anti-shake. The gyroscope sensor 180B can also be used for navigation and somatosensory game scenes.

[0254] Accelerometer 180E detects the magnitude of acceleration of the phone 100 in all directions (generally three axes). It can also detect the magnitude and direction of gravity when the phone 100 is stationary. It can also be used to identify the electronic device's posture, enabling applications such as switching between landscape and portrait modes and pedometers.

[0255] Distance sensor 180F is used to measure distance. Mobile phone 100 can measure distance using infrared or laser. In some embodiments, when shooting a scene, mobile phone 100 can use distance sensor 180F to measure distance to achieve fast focus.

[0256] The fingerprint sensor 180H is used to collect fingerprints. The mobile phone 100 can use the collected fingerprint characteristics to achieve fingerprint unlocking, access application locks, fingerprint photography, fingerprint call answering, etc.

[0257] The touch sensor 180K is also called a "touch device." The touch sensor 180K can be disposed on the display screen 194. The touch sensor 180K and the display screen 194 form a touch screen, also called a "touch screen." The touch sensor 180K is used to detect touch operations applied thereto or in the vicinity thereof. The touch sensor can transmit the detected touch operations to the application processor to determine the type of touch event. Visual output related to the touch operations can be provided via the display screen 194. In other embodiments, the touch sensor 180K can also be disposed on the surface of the mobile phone 100, in a location different from that of the display screen 194.

[0258] Keys 190 include a power button, a volume button, and the like. Keys 190 may be mechanical keys or touch-sensitive keys. Mobile phone 100 may receive key inputs and generate key signal inputs related to user settings and function control of mobile phone 100.

[0259] 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. For touch operations acting on different areas of the display screen 194, motor 191 can also correspond to different vibration feedback effects. Different application scenarios (for example: 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.

[0260] The indicator 192 may be an indicator light, which may be used to indicate the charging status, power level changes, messages, missed calls, notifications, etc.

[0261] The SIM card interface 195 is used to connect a SIM card. The SIM card can be connected to or disconnected from the mobile phone 100 by inserting or removing the SIM card into or from the SIM card interface 195.

[0262] Figure 13 is a schematic block diagram of a distributed system architecture provided by an embodiment of the present invention. This distributed system architecture can be applied to electronic devices such as the mobile phone 100 and computer 200 described above to implement the file sharing method provided by the embodiment of the present application. The distributed system shown in Figure 13 is exemplarily described below using mobile phone 100 and computer 200 as examples.

[0263] As shown in FIG13 , the distributed system architecture includes an application layer, an application framework layer, a system service layer, and a kernel layer.

[0264] The application layer may include a series of application packages, which may include applications such as the launcher, settings, and music, and may also include calendar, WLAN, Bluetooth, camera, gallery, call, map, video, etc., without limitation.

[0265] The application framework layer provides a distributed framework and lightweight device proxy services for the application layer. This distributed framework includes remote installation, remote startup, migration management, remote invocation, distributed system service management, and FA association management, enabling interoperability within and between systems (including startup, invocation, and migration), as well as the corresponding Application Programming Interface (API) for each framework.

[0266] The system service layer is the core of the distributed operating system. It provides services to applications and SDKs in the application layer through the application framework layer. The system service layer can include distributed sharing services, distributed file systems, and distributed soft buses.

[0267] Among them, the distributed sharing service is used to provide cross-device sharing capabilities for electronic devices such as mobile phones 100 and computers 200. For example, the mobile phone 100 can select a remote target device based on the distributed sharing service to open the locally shared target file. In addition, the distributed sharing service can use the distributed file system on the mobile phone 100 to map the local target file of the mobile phone 100 to a distributed file and generate a distributed file URI. In addition, the distributed sharing service can also set the authorization information and security management policy for the target device corresponding to the distributed file created by mapping the target file in the distributed file system. Furthermore, the distributed sharing service can complete the process of authorizing the target device to read and write the distributed file and share it with the target device by sending the distributed file URI to the target device.

[0268] A distributed file system is used to provide different electronic devices with access to the same file resources. For example, mobile phone 100 can access files on computer 200 under the same operating system using a distributed file system, and computer 200 can also access files on mobile phone 100 under the same operating system using a distributed file system.

[0269] The distributed soft bus, as an example structure of the underlying network, is used to transmit display data between devices and control instructions across devices, thus realizing Harmony distributed flow. For understanding the function of the distributed soft bus, one can refer to the computer hardware bus. For example, the distributed soft bus builds an "invisible" bus between 1+8+N devices (1 is a mobile phone; 8 represents car computers, speakers, headphones, watches, bracelets, tablets, large screens, personal computers (PCs), augmented reality (AR), virtual reality (VR); N refers to other Internet of Things (IOT) devices). It has the characteristics of automatic discovery, instant connection, self-organizing networking (heterogeneous network networking), high bandwidth, low latency, and high reliability. In other words, through the distributed soft bus technology, not only can all data be shared between devices, but they can also be instantly connected to any device on the same local area network or connected to it via Bluetooth. In addition, the distributed soft bus can also share files between heterogeneous networks such as Bluetooth and Wireless-Fidelity (Wi-Fi) (for example, receiving files via Bluetooth on the one hand and transmitting files via WiFi on the other hand).

[0270] The kernel layer is the layer between hardware and software. The kernel layer of a distributed operating system consists of the kernel subsystem and the driver subsystem. Because distributed operating systems can employ multi-core designs, the kernel subsystem supports the selection of appropriate OS kernels for different resource-constrained devices.

[0271] The Kernel Abstraction Layer (KAL) on the kernel subsystem shields the differences between multiple kernels and provides basic kernel capabilities to the upper layer, including process / thread management, memory management, file system, network management, and peripheral management.

[0272] The driver framework provided by the driver subsystem is the foundation for the openness of the distributed system hardware ecosystem, providing unified peripheral access capabilities and a driver development and management framework. The kernel layer includes at least display drivers, camera drivers, audio drivers, and sensor drivers.

[0273] References in the specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one exemplary implementation or technique disclosed according to the embodiment of the present application. The appearances of the phrase "in one embodiment" in various places in the specification do not necessarily all refer to the same embodiment.

[0274] The disclosure of the embodiments of the present application also relates to an operating device for executing the text. The device can be constructed specifically for the required purpose or it can include a general-purpose computer that is selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can be stored in a computer-readable medium, such as, but not limited to, any type of disk, including a floppy disk, an optical disk, a CD-ROM, a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an EPROM, an EEPROM, a magnetic or optical card, an application-specific integrated circuit (ASIC) or any type of medium suitable for storing electronic instructions, and each can be coupled to a computer system bus. In addition, the computer mentioned in the specification can include a single processor or can be an architecture involving multiple processors for increased computing power.

[0275] In addition, the language used in this specification has been primarily selected for readability and instructional purposes and may not be selected to describe or limit the disclosed subject matter. Therefore, the present disclosure of embodiments is intended to illustrate, not to limit, the scope of the concepts discussed herein.

Claims

1. A method for sharing files, characterized in that: The method comprises: In response to the first electronic device detecting a first sharing operation instructing a user to share the first file with the second electronic device, the second electronic device displays the first file; In response to the first electronic device detecting that the first file meets the first condition for ending sharing, the second electronic device stops displaying the first file, wherein the first condition includes that the sharing permission information corresponding to the second electronic device cannot be matched, or the matching sharing permission information corresponding to the second electronic device has expired.

2. The method according to claim 1, characterized in that The inability to match the sharing permission information corresponding to the second electronic device includes that the first electronic device has not set the sharing permission information of the first file to the second electronic device; The matched sharing permission information corresponding to the second electronic device has expired, including that the sharing permission information of the first file set in the first electronic device for the second electronic device has been deleted.

3. The method according to claim 1, characterized in that The first electronic device detecting that the first file meets a first condition for ending sharing includes: The first electronic device cannot match the first permission information corresponding to the second electronic device based on the at least one sharing permission information corresponding to the first file; or The first electronic device determines that the first permission information has expired based on a first management and control policy corresponding to the first file, and The method further comprises: In response to the first electronic device detecting that the user opens the first file on the second electronic device, a prompt interface is displayed on the second electronic device, where the prompt interface is used to prompt that the second electronic device does not have access rights to the first file.

4. The method according to claim 3, characterized in that The first control strategy includes: a timeout expiration policy, configured to invalidate the first permission information when it is detected that the first permission information has not been used for a period exceeding a preset expiration time; and / or, The link-breaking invalidation strategy is used to invalidate the first permission information when it is detected that the communication connection between the first electronic device and the second electronic device is disconnected.

5. The method according to claim 4, characterized in that The first electronic device determining, based on a first management and control policy corresponding to the first file, that the first permission information has expired includes: The first electronic device detects that the first permission information has not been used for more than a preset expiration time, and deletes the first permission information based on the timeout expiration policy; or The first electronic device detects that the communication connection between the first electronic device and the second electronic device is disconnected, and deletes the first permission information based on the disconnection invalidation policy.

6. The method according to any one of claims 1 to 3, characterized in that The first electronic device includes a distributed file system, and The first electronic device detects a first sharing operation instructing a user to share a first file with a second electronic device, including: In response to the first sharing operation, the first electronic device creates a first mapping file corresponding to the first file in a distributed file system, wherein a first mapping relationship exists between the first file and the first mapping file; The first electronic device sets first permission information and a first management and control policy in the created first mapping file; The first electronic device sends a first sharing request to the second electronic device, where the first sharing request includes a global identifier of the first mapping file, and the global identifier is a unique identifier of the first mapping file in the first electronic device.

7. The method according to claim 6, characterized in that The global identifier includes a uniform resource identifier (URI) of the first mapping file, and the second electronic device displays the first file, comprising: The second electronic device opens the first file in response to the first sharing request based on the URI of the first mapping file and the first mapping relationship; or The second electronic device obtains the first file in response to the first sharing request based on the URI in the first sharing request and the first mapping relationship.

8. The method according to claim 7, characterized in that The first sharing request further includes a first application identifier of a first application, wherein the first application is an application installed on the second electronic device; and, The second electronic device displays the first file, including: The second electronic device opens the first file through the first application in response to the first sharing request based on the URI in the first sharing request, the first application identifier, and the first mapping relationship; or, In response to the first sharing request, the second electronic device acquires the first file into a memory space corresponding to the first application based on the URI in the first sharing request, the first application identifier, and the first mapping relationship.

9. The method according to any one of claims 6 to 8, characterized in that The first file and the first mapping file both include a file structure, a dentry structure, and an inode structure, and the first mapping relationship includes: The file structure of the first file is mapped correspondingly to the file structure of the first mapping file, and, The dentry structure of the first file is mapped to the dentry structure of the first mapping file, and The inode structure of the first file is mapped correspondingly to the inode structure of the first mapping file.

10. The method according to claim 9, characterized in that The first electronic device sets the first permission information and the first management and control policy in the created first mapping file, including: The first permission information and the first control policy are set in the dentry structure of the first mapping file.

11. The method according to any one of claims 1 to 10, characterized in that The first sharing operation includes: An opening operation on the first file, or A copy operation is performed on the first file.

12. The method according to claim 3, characterized in that The prompt interface displays a prompt message to prompt that the second electronic device does not have access rights to the first file, wherein: The prompt information includes content indicating that the first file does not exist.

13. A method for sharing files, applied to a first electronic device, characterized in that: The method comprises: detecting a first sharing operation instructing a user to share a first file with a second electronic device, and sending a first sharing request to the second electronic device, wherein the first sharing request is used to instruct the second electronic device to display the first file; It is detected that the first file meets the first condition for ending sharing, and a notification of ending sharing is sent to the second electronic device, wherein the first condition includes that the sharing permission information corresponding to the second electronic device cannot be matched, or the matching sharing permission information corresponding to the second electronic device has expired.

14. The method according to claim 13, characterized in that The detecting that the first file meets the first condition for ending sharing includes: The at least one sharing permission information corresponding to the first file cannot be matched with the first permission information corresponding to the second electronic device; or Determining that the first permission information has expired based on a first management and control policy corresponding to the first file, and The method further comprises: Detecting that a user opens the first file on a second electronic device, sending a prompt message to the second electronic device, wherein the prompt message is used to instruct the second electronic device to display a prompt interface, and the prompt interface is used to prompt that the second electronic device does not have access rights to the first file.

15. The method according to claim 14, characterized in that The first control strategy includes: a timeout expiration policy, configured to invalidate the first permission information when it is detected that the first permission information has not been used for a period exceeding a preset expiration time; and / or, The link-breaking invalidation strategy is used to invalidate the first permission information when it is detected that the communication connection between the first electronic device and the second electronic device is disconnected.

16. The method according to claim 14, characterized in that The first electronic device includes a distributed file system, and The detecting a first sharing operation instructing a user to share a first file with a second electronic device includes: In response to the first sharing operation, creating a first mapping file corresponding to the first file in the distributed file system, wherein a first mapping relationship exists between the first file and the first mapping file; Setting the first permission information and the first control policy in the created first mapping file; The first sharing request is sent to the second electronic device, where the first sharing request includes a global identifier of the first mapping file, and the global identifier is a unique identifier of the first mapping file in the first electronic device.

17. The method according to claim 16, characterized in that The first file and the first mapping file both include a file structure, a dentry structure, and an inode structure, and the first mapping relationship includes: The file structure of the first file is mapped correspondingly to the file structure of the first mapping file, and, The dentry structure of the first file is mapped to the dentry structure of the first mapping file, and The inode structure of the first file is mapped correspondingly to the inode structure of the first mapping file.

18. The method according to claim 17, characterized in that The setting of the first permission information and the first control policy in the created first mapping file includes: The first permission information and the first control policy are set in the dentry structure of the first mapping file.

19. A method for sharing files, applied to a second electronic device, characterized in that: The method comprises: In response to receiving a first sharing request corresponding to a first file, displaying the first file, wherein the first sharing request is a request generated by the first electronic device in response to a first sharing operation of a user, and the first sharing operation is an operation instructing to share the first file with the second electronic device; In response to receiving a notification corresponding to the end of sharing of the first file, stop displaying the first file, wherein the notification of the end of sharing is a notification generated by the first electronic device when it detects that the first file meets the first condition for ending sharing, and the first condition includes that the sharing permission information corresponding to the second electronic device cannot be matched, or the matching sharing permission information corresponding to the second electronic device has expired.

20. The method according to claim 19, characterized in that The response to the received notification of ending sharing of the first file further includes: A prompt interface is displayed, where the prompt interface is used to prompt that the second electronic device does not have access rights to the first file.

21. The method according to claim 19 or 20, characterized in that The first sharing request includes a global identifier of a first mapping file, wherein the first mapping file is a file created by the first electronic device in a distributed file system in response to the first sharing operation, and a first mapping relationship exists between the first mapping file and the first file, and the global identifier is a unique identifier of the first mapping file in the first electronic device.

22. The method according to claim 21, characterized in that The global identifier includes a uniform resource identifier (URI) of the first mapping file, and The step of displaying the first file in response to the received first sharing request corresponding to the first file includes: In response to the first sharing request, opening the first file based on the URI of the first mapping file and the first mapping relationship; or, In response to the first sharing request, the first file is acquired based on the URI in the first sharing request and the first mapping relationship.

23. The method according to claim 22, characterized in that The first sharing request further includes a first application identifier of a first application, wherein the first application is an application installed on the second electronic device; and, The step of displaying the first file in response to the received first sharing request corresponding to the first file includes: In response to the first sharing request, opening the first file through the first application based on the URI in the first sharing request, the first application identifier, and the first mapping relationship; or, In response to the first sharing request, based on the URI in the first sharing request, the first application identifier, and the first mapping relationship, the first file is acquired into a memory space corresponding to the first application.

24. An electronic device, characterized in that: include: one or more processors; One or more memories; the one or more memories store one or more programs, and when the one or more programs are executed by the one or more processors, the electronic device executes the method for sharing files according to any one of claims 1 to 23.

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

Images