CN115834128A

CN115834128A - File access method and device

Info

Publication number: CN115834128A
Application number: CN202211303429.9A
Authority: CN
Inventors: 潘添翼
Original assignee: Hangzhou Hikvision Digital Technology Co Ltd
Current assignee: Hangzhou Hikvision Digital Technology Co Ltd
Priority date: 2022-10-24
Filing date: 2022-10-24
Publication date: 2023-03-21

Abstract

The embodiment of the application provides a file access method and a device, which relate to the technical field of communication, wherein the method comprises the following steps: mapping a first file directory in the local file system to a second file directory in a file system of the second device; after receiving an access request for a target file sent by the second device, if the target file is a file allowing a target application program to access, responding to the access request, wherein the target application program is: an application program in the second device requesting access to the target file, where the target file is a file in the first file directory, and the access request is: the target application program generates a request according to the mapping path of the target file in the second file directory; otherwise, responding to the access request under the condition that the target application program is a trusted signature program. By applying the scheme provided by the embodiment of the application, file access between devices can be realized.

Description

File access method and device

Technical Field

The present application relates to the field of communications technologies, and in particular, to a file access method and apparatus.

Background

With the rapid development of the internet of things technology, interconnection and intercommunication among various devices are more and more common, data interaction among the devices is more and more common, and the requirement for cross-device file access is more and more frequent.

Therefore, it is desirable to provide a file access scheme to enable file access between devices.

Disclosure of Invention

An embodiment of the present application aims to provide a file access method and apparatus, so as to implement file access between devices. The specific technical scheme is as follows:

in a first aspect, an embodiment of the present application provides a file access method, which is applied to a first device, and the method includes:

mapping a first file directory in the local file system to a second file directory in a file system of the second device;

after receiving an access request for a target file sent by the second device, if the target file is a file allowing a target application program to access, responding to the access request, wherein the target application program is: an application program in the second device requesting to access the target file, where the target file is a file in the first file directory, and the access request is: the target application program generates a request according to the mapping path of the target file in the second file directory;

otherwise, responding to the access request under the condition that the target application program is a trusted signature program.

In one embodiment of the present application, it is determined whether the target application is a trusted signature program by:

obtaining a signature file of the target application from the second device;

if the target application program is a system program and the signature file has a system label, determining that the target application program is a trusted signature program;

and if the target application program is a third-party program and the signature file is valid, verifying the target application program according to signature information and verification information contained in the signature file, and determining that the target application program is a trusted signature program under the condition that the verification is passed.

In one embodiment of the present application, it is determined whether the target file is a file that the target application is allowed to access by:

obtaining a process identification of the target application from the second device;

and determining whether the target file is a file which is allowed to be accessed by the target application program or not based on the process identification.

In an embodiment of the application, the responding to the access request includes:

obtaining a mapping path of the target file under the second file directory;

if the mapping path is an effective path, responding to the access request based on the mapping path;

if the mapping path is an invalid path, obtaining an original path of the target file in the first file directory, repairing the mapping path based on the original path, and responding to the access request based on the repaired mapping path.

if a plurality of unresponsive requests for accessing the target file exist, determining a response sequence between the access request and other requests;

locking the access thread for responding to the access request when the sequence for responding to the access request is not reached;

and when the order of responding to the access requests is reached, unlocking the access threads, and responding to the access requests based on the access threads.

In a second aspect, an embodiment of the present application provides a file access apparatus, which is applied to a first device, and the apparatus includes:

the file directory mapping module is used for mapping a first file directory in the local file system to a second file directory in the file system of the second device;

a first access request response module, configured to, after receiving an access request for a target file sent by the second device, respond to the access request if the target file is a file allowing access of a target application program, and otherwise, trigger a second access request response module, where the target application program is: an application program in the second device requesting to access the target file, where the target file is a file in the first file directory, and the access request is: the target application program generates a request according to the mapping path of the target file in the second file directory;

and the second access request response module is used for responding to the access request under the condition that the target application program is a trusted signature program.

In one embodiment of the present application, whether the target application is a trusted signature program is determined by:

obtaining a signature file of the target application from the second device; if the target application program is a system program and the signature file has a system label, determining that the target application program is a trusted signature program; and if the target application program is a third-party program and the signature file is valid, verifying the target application program according to signature information and verification information contained in the signature file, and determining that the target application program is a trusted signature program under the condition that the verification is passed.

obtaining a process identification of the target application from the second device; and determining whether the target file is a file which is allowed to be accessed by the target application program or not based on the process identification.

obtaining a mapping path of the target file under the second file directory; if the mapping path is an effective path, responding to the access request based on the mapping path; if the mapping path is an invalid path, obtaining an original path of the target file in the first file directory, repairing the mapping path based on the original path, and responding to the access request based on the repaired mapping path.

if a plurality of unresponsive requests for accessing the target file exist, determining a response sequence between the access request and other requests; locking the access threads used for responding to the access requests when the sequence of responding to the access requests is not reached; and when the order of responding to the access requests is reached, unlocking the access threads, and responding to the access requests based on the access threads.

In a third aspect, an embodiment of the present application provides an electronic device, including:

a memory for storing a computer program;

a processor, configured to implement the file access method according to the first aspect when executing the program stored in the memory.

In a fourth aspect, the present application provides a computer-readable storage medium, in which a computer program is stored, and when executed by a processor, the computer program implements the file access method according to the foregoing first aspect.

In a fifth aspect, embodiments of the present application further provide a computer program product containing instructions, which when run on a computer, cause the computer to execute the file access method according to the first aspect.

As can be seen from the above, when a file is accessed by applying the scheme provided in the embodiment of the present application, first mapping the first file directory in the local file system to the second file directory in the file system of the second device, so that the target application program in the second device can access the first file directory through the second file directory, and determine the target file in the first file directory to be accessed, and then the second device can send an access request for the target file to the first device, and the first device can respond to the access request, so that the target application program in the second device successfully accesses the target file in the first device, thereby implementing the cross-device file access.

In addition, after receiving an access request for a target file sent by the second device, the first device also judges whether to respond to the access request according to the access authority of a target application program in the second device for the target file, wherein the access request is responded under the condition that the target file is a file allowing the target application program to access; and if the signature program is the credible signature program, responding to the access request. Therefore, when the access request is responded, multiple authentications are carried out on the application program accessing the target file in the second device, and the access request is responded only when the target application program meets the access requirement, so that the target application program is allowed to access the target file, and thus the access request of the malicious application program for the target file is favorably filtered, the target file in the first device is favorably prevented from being stolen and spread by the malicious application program, and the security of the file in the first device is improved when the cross-device file is accessed.

Of course, not all advantages described above need to be achieved at the same time in the practice of any one product or method of the present application.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and it is also obvious for a person skilled in the art to obtain other embodiments according to the drawings.

Fig. 1 is a schematic flowchart of a first file access method according to an embodiment of the present application;

fig. 2 is a schematic flowchart of a second file access method according to an embodiment of the present application;

fig. 3 is a schematic flowchart of a third file access method according to an embodiment of the present application;

fig. 4 is a schematic structural diagram of a file access device according to an embodiment of the present application;

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

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments that can be derived by one of ordinary skill in the art from the description herein are intended to be within the scope of the present disclosure.

First, an execution subject of the scheme provided in the embodiment of the present application will be described.

The scheme provided by the embodiment of the application has the following main execution bodies: and the electronic equipment receives the file access request initiated by the access initiating equipment and responds based on the access request.

The electronic device that responds may be referred to as a first device in the solution provided in the embodiment of the present application, and the access initiating device may be referred to as a second device in the solution provided in the embodiment of the present application.

The following describes in detail a file access method provided in an embodiment of the present application.

Referring to fig. 1, fig. 1 is a schematic flowchart of a first file access method provided in an embodiment of the present application, and is applied to a first device, where the method includes the following steps S101 to S105.

Step S101: a first file directory in the local file system is mapped to a second file directory in the file system of the second device.

The local file system is a software system in the operating system of the first device that is responsible for managing and storing file information.

The following situations may be mentioned for the contents of the first file directory in the file system mapped to the second device in the local file system.

In the first case, the first file directory may be the entire file directory in the local file system.

In the second case, the first file directory may be a partial file directory preset in the local file system. For example, the preset partial file directory is a file directory set with an access authority.

In a third case, the first device may determine, based on the first identifier of the file directory to be accessed, sent by the second device, the file directory indicated by the first identifier in the local file system as the first file directory.

This situation is applicable to the second device having accessed the file in the first device before, that is, the file system of the second device has a mapping of the file directory in the file system of the first device, so that the second device may record the file directory, and when accessing this time, use the file directory as the file directory to be accessed or use a part of the file directory in the file directory as the file directory to be accessed, and then send the first identifier of the file directory to be accessed to the first device.

The directory mapping method will be described below.

Specifically, the first device may receive a second identifier of a second file directory sent by the second device, and mount the first file directory to the second file directory indicated by the second identifier. In this case, the second file directory may be referred to as a mount point.

Of course, in this step, before the first device maps the first file directory in the local file system to the second file directory in the file system of the second device, essential basic steps such as establishing a communication connection with the second device and initializing the local file system are further included, and details of these steps are described in the following embodiments and will not be described in detail here.

Step S102: and receiving an access request for the target file sent by the second device.

The target file is a file in the first file directory, and the access request is a request generated by the target application program according to a mapping path of the target file in the second file directory.

The target application program is an application program that requests to access the target file in the second device, and may be an application program used for opening, playing, editing, and the like of the target file, for example, the target application program may be a text editing application, an audio playing application, a video playing application, a compressed package viewing application, and the like.

Since the second file directory is a file directory in a file system of the second device, after the first file directory is mapped to the second file directory, the target application program in the second device can access the first file directory through the second file directory, and further determine a target file in the first file directory to be accessed, thereby generating an access request for the target file. And the path of the target file in the second file directory is the mapping path.

As can be seen from the above description, the actual path of each file contained in the first file directory corresponds to the mapping path in the second file directory.

Step S103: and judging whether the target file is a file allowing the target application program to access, if so, executing the step S104, and if not, executing the step S105.

In this step, it is determined whether the target file is a file that allows the target application to access, or whether the target application has a right to access the target file.

The following describes specific ways of determining whether a target file is a file that is allowed to be accessed by a target application.

Specifically, the process identifier of the target application may be obtained from the second device, and based on the process identifier, it is determined whether the target file is a file that is allowed to be accessed by the target application.

The process identifier may be a User Identification (UID) of the process, and may represent a User level of the process creator; or may be a PID (Process Identification), which may characterize information such as the creation order of the Process.

Of course, the Process identifier may also be an EUID (Effective User Identification), a PPID (Parent Process Identification), and the like, which is not limited in this application.

Specifically, according to the difference between the process identifiers, the following description will be given by exemplifying a manner of determining whether the target file is a file that is allowed to be accessed by the target application program based on the process identifiers.

In one embodiment, the process is identified as a UID, and in this case, whether the target file is a file that allows the target application to access may be determined based on a user level corresponding to the UID.

Specifically, it may be determined whether the UID belongs to a UID set of a preset user level corresponding to the target file, and if so, the target file is determined to be a file that allows the target application program to access.

For example, the UID set corresponding to the target file f1 is {0}, where the set is a UID set of a user level that is a root user (also referred to as a super user), and this indicates that the target application program can access the target file when the process creator of the target application program is the root user; for another example, the UID set corresponding to the target file f2 is {1,2,3, …,499}, which is the UID set of the system user, and indicates that the target application can access the target file when the process creator of the target application is the system user.

In another embodiment, the process identifier is a PID, in which case, it may be determined whether the PID is in a preset format, and if so, it may be determined that the target file is a file that is allowed to be accessed by the target application program.

The second device may allocate a PID to the target application according to the preset format, so that when the second device detects that the PID of the target application is in the preset format, the target file is determined to be a file that the target application is allowed to access.

Therefore, the target application program which is created by the second device and has the corresponding PID in the preset format can only access the target file, and when the malicious application program in the second device does not authorize the creation process, the corresponding PID is probably not in the preset format, so that the target file is favorably determined as the file which is not allowed to be accessed by the malicious application program according to the PID.

It should be noted that the embodiment of the present application does not limit the specific content of the preset format, for example, the preset format may be a value interval of a first bit of a PID, a parity type of a last bit of the PID, and the like.

In another embodiment, the process identifier includes a UID and a PID, and in this case, the two embodiments may be combined, and when the UID is determined to belong to a UID set of a preset user level corresponding to the target file and/or the PID is determined to be in a preset format, the target file is determined to be a file that allows the target application program to access.

The process identifier of the application program can represent information such as the user level of a process creator, the creation order of the process and the like, and can be used for identifying one process, so that the access authority of the target application program for the target file can be accurately and conveniently judged by taking the process identifier of the target application program as a basis.

Step S104: and responding to the access request.

If the target file is a file which allows the target application program to access, the first device can respond to the access request sent by the second device, so that the target application program in the second device is allowed to access the target file in the first device.

Specifically, the following describes the manner of responding to an access request from a different perspective.

In one case, from the perspective of determining an operation that can be performed on the target file by the target application, the first device may further determine an executable operation of the target file when responding to the access request, so that the target application operates the target file within the range of the executable operation. The executable operation can be read from the attribute information of the target file, and can include whether reading is allowed or not, whether writing is allowed or not, and the like.

In another case, from the perspective of preventing the multi-target application program from accessing the target file at the same time, the first device may determine a response sequence between each access request and another request, lock or unlock an access thread for each access request based on the response sequence, and respond to the access request based on the access thread when the access thread is unlocked. Detailed description of the preferred embodimentsthe embodiment shown in fig. 1 will be described in detail later, and will not be described in detail herein.

In another case, from the perspective of whether the target application in the second device can successfully access the target file, the first device may obtain a mapping path of the target file in the second file directory, and respond to the access request in different ways based on whether the mapping path is valid or not. The detailed description will be given in the following step S304-step S306 in the embodiment shown in fig. 3, and will not be described in detail here.

Step S105: and judging whether the target application program is a trusted signature program, and if so, executing the step S104.

The trusted signature program represents an application program which is downloaded from a legal channel and is installed and authenticated through signature, the security of a target file in the first device cannot be threatened, and even if the target file is not a file which the target application program allows to access, the target application program can be allowed to access under the condition that the target application program is the trusted signature program.

Therefore, in this step, when the target file is not a file that the target application allows to access, it is determined whether the target application is a trusted signature program, and if so, the target application in the second device is allowed to access the target file in response to an access request sent by the second device.

Specifically, whether the target application is an authentic signature program may be determined in the following manner.

In one embodiment, it may be determined whether the target application is an application in a trusted signature program list recorded locally, if so, it may be determined that the target application is a trusted signature program, and if not, it may be determined that the target application is not a trusted signature program.

In another embodiment, the signature file of the target application program may be obtained first, and then, according to whether the target application program belongs to the system application program, whether the target program is a trusted signature program may be determined based on the signature file in a different manner. The detailed description is provided in the following step S205-step S210 in the embodiment shown in fig. 2, and will not be described in detail here.

In addition, after receiving an access request for a target file sent by the second device, the first device also judges whether to respond to the access request according to the access authority of a target application program in the second device for the target file and whether the target application program is a trusted signature program, wherein the access request is responded to when the target file is a file allowing the target application program to access; otherwise, further judging the credible signature program for the application program, and responding to the access request only if the application program is the credible signature program. Therefore, when the access request is responded, multiple authentications are carried out on the application program accessing the target file in the second device, and the access request is responded only when the target application program meets the access requirement, so that the target application program is allowed to access the target file, and thus the access request of the malicious application program for the target file is favorably filtered, the target file in the first device is favorably prevented from being stolen and spread by the malicious application program, and the security of the file in the first device is improved when the cross-device file is accessed.

In addition, in the prior art, cross-device file access is often realized based on a screen-casting mode, a file is played by an accessed device in real time, a data stream of the played content is sent to an access initiating device, and the access initiating device locally displays the played content of the accessed device according to the received data stream. However, the above-mentioned solution can only support displaying, at the access initiating device, files that can be played by pictures, audio, video, etc. in the accessed device, and cannot enable the access initiating device to access files in other formats, such as documents, compressed packages, etc. in the accessed device.

When the scheme provided by the embodiment of the application is adopted for file access, the second device can access various types of files in the first device only by the first device and the second device having network transmission capability, so that the compatibility during file access is improved.

The essential basic steps before the aforementioned step S101 is performed will be explained below by means of step a and step B.

Step A: a communication connection is established with a second device.

Establishing a communication connection with a second device may be either first device initiated or second device initiated.

For example, the first device may receive a communication connection establishment request sent by the second device, and establish a communication connection with the second device based on the received establishment request.

Specifically, the first device may establish a communication connection with the second device in the following manner.

In one embodiment, after receiving a communication connection establishment request sent by a second device, a first device may determine whether the second device and itself access the same trusted network, and if so, establish a communication connection with the second device.

Therefore, the first device and the second device are both in the same trusted network environment, network attack in the file access process is prevented, and the security in the file access process is improved.

In another embodiment, after receiving the communication connection establishment request sent by the second device, the first device may determine whether the communication connection establishment request is a request sent based on a reliable communication protocol, and if so, establish a communication connection with the second device.

The reliable communication Protocol may be a TCP (Transmission Control Protocol), a CAN (Controller Area Network) Protocol, or the like.

Therefore, the communication process is stable and reliable, and the stability of file access is improved.

In another embodiment, the two embodiments may be combined, and after receiving the communication connection establishment request sent by the second device, the first device establishes a communication connection with the second device when determining that the second device and itself are in the same trusted network and the communication connection establishment request is a request sent based on a reliable communication protocol.

And B: the local file system is initialized.

The local file system is loaded into an available state so that a first file directory in the local file system can subsequently be mapped to a second file directory in the file system of the second device. This step is typically performed before step a described above, e.g. initially performed by the first device, and is not required to be performed each time a communication connection is established or each time a file in the first device is accessed.

In addition, the step a is not executed each time the file in the first device is accessed by the second device, and the step a need not be executed repeatedly as long as it is ensured that the communication connection between the first device and the second device is in an available state when the application program in the second device requests to access the file in the second device.

In the above-mentioned point of view of whether the target application in the second device can successfully access the target file, there may be other implementations of the step S104 in response to the access request, which are described below through steps C-E.

And C: and if a plurality of unresponsive requests for accessing the target file exist, determining the response sequence between the access requests and other requests.

Specifically, the response order of each access request can be determined in the following manner.

In one embodiment, the response sequence of each access request can be determined according to the request initiation time of each access request.

For example, the response order of the access requests is determined in the order of the request initiation time of the access requests from early to late.

In another embodiment, the response sequence of each access request may be determined according to the process identifier of the target application program in the second device that initiated each access request. The following description will be made by taking two modes as examples.

In a first mode, if the process identifier is the UID, the access requests may be sorted according to a sequence from high to low of the user level indicated by the UID, so as to obtain a response sequence. For the access requests with the same corresponding user level, time ordering may be initiated according to the request with reference to the foregoing embodiment.

In a second way, if the process identifier is PID, the access requests may be sorted according to the sequence of PID values from small to large, so as to obtain a response sequence.

Step D: and locking the access threads for responding to the access requests when the order of responding to the access requests is not reached.

And aiming at each access request, the first equipment creates an access thread for processing.

And locking the access thread corresponding to the access request which does not reach the response sequence, wherein the access thread is in a dormant state, that is, the first device does not respond to the access request corresponding to the access thread, so that the target application program in the second device initiating the access request cannot access the target file.

Step E: and when the order of responding to the access requests is reached, unlocking the access threads, and responding to the access requests based on the access threads.

And unlocking the access thread corresponding to the access request reaching the response sequence, activating the access thread, and responding to the access request corresponding to the access thread by the first device, so that the target application program in the second device initiating the access request can access the target file.

Therefore, the access requests are guaranteed to be processed according to the response sequence, response of multiple access requests at the same time is prevented, the problem that file data are disordered and the like due to the fact that multiple target application programs access the target files at the same time is solved, and stability of the file access process is improved.

In an embodiment of the application, the first device may further receive a file operator of the target file and modification information for the target file sent by the second device, and modify the target file in the local file system based on the received information.

The file operator is used for identifying a target file, and the modification information may be a modified target file or modified content for the target file.

Therefore, the user can remotely modify the target file in the first equipment in the second equipment, and convenience and flexibility in modifying the target file in the first equipment are improved.

On the basis of the foregoing embodiment shown in fig. 1, the signature file of the target application program may be obtained first, and then, according to whether the target application program belongs to the system application program, whether the target program is an authentic signature program may be determined in different manners based on the signature file. In view of the foregoing, a second file access method provided in the embodiments of the present application.

Referring to fig. 2, fig. 2 is a schematic flowchart of a second file access method provided in the embodiment of the present application, and is applied to a first device, where the method includes the following steps S201 to S210.

Step S201: a first file directory in the local file system is mapped to a second file directory in the file system of the second device.

Step S202: and receiving an access request for the target file sent by the second device.

Step S203: and judging whether the target file is a file allowing the target application program to access, if so, executing the step S204, and if not, executing the step S205.

Step S204: and responding to the access request.

The steps S201 to S204 can be obtained based on the steps S101 to S104 in the embodiment shown in fig. 1, and the differences are only the step numbers, which is not described herein again.

Step S205: a signature file of the target application is obtained from the second device.

The signature file is a file containing encryption authentication information and used for performing trusted authentication on the application program.

Specifically, the first device may receive a signature file carried by the second device when sending the access request, or may send an obtaining request for the signature file of the target application program to the second device, and then receive the signature file fed back by the second device.

Step S206: and judging whether the target application program is a system program, if so, executing step S207, and if not, executing step S208.

The system program may be an authenticated application developed inside the manufacturer of the first device, and may have a high degree of reliability. For example, if the first device is a monitoring camera, the system program may be an application program developed by a manufacturer of the monitoring camera and used for reading data stored in the monitoring camera.

Specifically, the first device may record an application package name of the system program, send an obtaining request for the application package name of the target application program to the second device, and determine whether the application package name fed back by the second device belongs to the application package name recorded in the first device, if so, the first device may determine that the target application program is the system program, and if not, the first device may determine that the target application program is the third-party program.

Step S207: and judging whether the system label exists in the signature file, if so, executing the step S204.

The system tag may be understood as a tag added to a signature file of the system application when the manufacturer of the first device develops the system application.

In order to prevent the target application program from being a counterfeit system application, the first device may further determine whether a system tag exists in the signature file of the target application program, and if so, may determine that the target application program is a real system application, that is, a trusted application program, and thus respond to the access request.

Step S208: and judging whether the signature file is valid, if so, executing the step S209.

If the first device determines that the target application program is not a system program but a third-party program, the first device may first determine whether the signature file is valid.

Specifically, the first device may determine whether the signature file is valid by determining whether the content of the signature file is correct, whether the format of the signature file is correct, whether the signature file is in the signature validity period, and the like.

If the signature file is valid, the signature file can be used for evaluating whether the target application program is a trusted signature program, and therefore the target application program can be further verified according to the signature information and the verification information contained in the signature file.

Step S209: and verifying the target application program according to the signature information and the verification information contained in the signature file.

The signature information may include a digital signature of the target application, and the verification information may include an encrypted public key of the digital signature.

Specifically, the encrypted public key may be used to decrypt the digital signature, and then the decrypted data is compared with the original text of the digital signature, if the decrypted data is consistent with the original text of the digital signature, it is determined that the target application program is verified, and if the decrypted data is inconsistent with the original text of the digital signature, it is determined that the target application program is not verified.

Step S210: and judging whether the verification is passed, if so, executing the step S204.

In case the verification passes, indicating that the target application is an authentic signature program, step S204 may be performed to respond to the access request of the second device.

As can be seen from the above, when the scheme provided in the embodiment of the present application is used to access a file, a determination is made on a trusted application program with respect to a target application program, and when the target application program is the trusted application program, an access request of the second device is responded, so that the target application program is allowed to access the target file. Therefore, the target file in the first equipment can be prevented from being accessed by the untrusted application program, and the safety of the target file in the first equipment is improved during file access.

In addition, the system application is an authenticated application developed in the first equipment manufacturer, and the reliability is high; in contrast, the third-party application is an application developed by a third-party developer, and the credibility of the application is low, and the embodiment of the application can judge whether the target application program is a trusted application program or not in different ways for the system program or the third-party program according to the target application program, so that whether the target application program is a trusted signature program or not can be judged more reasonably and effectively based on the characteristics of the system program or the third-party program.

Based on the embodiment shown in fig. 1, from the perspective of preventing multiple applications from accessing a target file at the same time, when responding to access requests, the first device may determine a response sequence between each access request and other requests, lock or unlock an access thread for each access request based on the response sequence, and respond to the access request based on the access thread when the access site is unlocked. In view of the foregoing, embodiments of the present application provide a third file access method.

Referring to fig. 3, a flowchart of a third file access method provided in the embodiment of the present application is applied to a first device, where the method includes the following steps S301 to S307.

Step S301: the first file directory in the local file system is mapped to a second file directory in the file system of the second device.

Step S302: and receiving an access request for the target file sent by the second device.

The step S301 and the step S302 can be obtained on the basis of the step S101 and the step S102 in the embodiment shown in fig. 1, and the differences are only the step numbers, which is not described herein again.

Step S303: and judging whether the target file is a file allowing the target application program to access, if so, executing step S304, and if not, executing step S307.

In this step, the manner of determining whether the target file is a file that allows the target application program to access is described in detail in step S103 in the embodiment shown in fig. 1, and details are not described here.

Step S304: and obtaining a mapping path of the target file in the second file directory.

Specifically, the first device may receive the mapping path carried by the second device when sending the access request, or send an obtaining request of the mapping path to the second device, and then receive the mapping path fed back by the second device.

Step S305: and if the mapping path is a valid path, responding to the access request based on the mapping path.

Specifically, whether the mapping path is a valid path may be determined in the following manner.

In an embodiment, it may be determined whether a target file exists in an actual path corresponding to the mapping path in a first file directory of a local file system, that is, whether the actual path corresponding to the mapping path can access the target file, if so, the mapping path is determined to be a valid path, and if not, the mapping path is determined to be an invalid path.

In another embodiment, when the mapping path is in a legal path format, it may be determined whether an actual path corresponding to the mapping path can access the target file, if so, the mapping path is determined to be a valid path, and if not, the mapping path is determined to be an invalid path.

If the mapping path is determined to be an effective path, in this case, the target application program in the second device may access the target file according to the mapping path, and therefore, the access request may be responded to the mapping path, so that the target application program in the second device accesses the target file according to the mapping path.

Step S306: and if the mapping path is an invalid path, acquiring an original path of the target file in the first file directory, repairing the mapping path based on the original path, and responding to the access request based on the repaired mapping path.

The specific manner for determining whether the mapping path is the valid path is described in step S305, and is not described herein again.

And if the mapping path is an invalid path, indicating that the actual path corresponding to the mapping path does not have the target file.

For example, when the actual path of the target file in the first device is changed, the original actual path corresponding to the mapping path does not have the target file; or under the condition of network fluctuation, the mapping between the second file directory in the first device and the second file directory in the second device is interrupted, and at this time, the original actual path corresponding to the mapping path does not have the target file.

In this case, the second device cannot access the target file according to the mapping path, and therefore, the original path of the target file in the first file directory can be obtained, and the mapping path can be repaired based on the original path.

The following describes a manner of repairing a mapped path based on an original path.

In one embodiment, the file directory where the original path is located may be mapped to the second file directory, so that the second device may determine a new actual path of the target file according to the mapping path of the target file in the second file directory, where the new actual path is the original path.

In another embodiment, a mapping relationship may be established only for the mapping path and the original path, and the mapping relationship may be sent to the second device, so that the second device may determine the original path of the target file according to the mapping path and the mapping relationship.

Specifically, after the mapped path is repaired based on the original path, the original path may be sent to the second device in response to the access request, so that the second device accesses the target file based on the original path.

Step S307: and judging whether the target application program is a trusted signature program, and if so, executing the step S304.

In this step, the method for determining whether the target application program is the trusted signature program is described in detail in step S205 to step S210 in the embodiment shown in fig. 2, and details thereof are not repeated here.

As can be seen from the above, when file access is performed by applying the scheme provided in the embodiment of the present application, after it is determined that the target application program located in the second device has the access right for the target file in the first device, it may be further determined whether the mapping path of the target file in the second file directory is valid, so that the mapping path may be repaired based on the original path of the target file in the first file directory under the condition that the mapping path is invalid, so that the target application program may successfully access the target file, which is beneficial to improving the access success rate of the target application program for the target file under the condition that the target application program has the access right, and improving the efficiency of file access.

Corresponding to the file access method, the embodiment of the invention provides a file access device.

Referring to fig. 4, fig. 4 is a schematic structural diagram of a file access device according to an embodiment of the present application, where the file access device includes the following modules 401 to 403.

A file directory mapping module 401, configured to map a first file directory in the local file system to a second file directory in the file system of the second device;

a first access request response module 402, configured to, after receiving an access request for a target file sent by the second device, respond to the access request if the target file is a file that allows a target application program to access, and otherwise, trigger a second access request response module, where the target application program is: an application program in the second device requesting access to the target file, where the target file is a file in the first file directory, and the access request is: the target application program generates a request according to the mapping path of the target file in the second file directory;

a second access request responding module 403, configured to respond to the access request if the target application is a trusted signature program.

In addition, after receiving an access request for a target file sent by the second device, the first device also judges whether to respond to the access request according to the access authority of a target application program in the second device for the target file and whether the target application program is a trusted signature program, wherein the access request is responded to when the target file is a file allowing the target application program to access; otherwise, further judging the credible signature program for the application program, and responding to the access request only if the application program is the credible signature program. Therefore, when the access request is responded, multiple authentications are carried out on the application program accessing the target file in the second device, the target application program is ensured to respond to the access request only when meeting the access requirement, and the target application program is allowed to access the target file, so that the access request of the malicious application program aiming at the target file is favorably filtered, the target file in the first device is favorably prevented from being stolen and spread by the malicious application program, and the safety of the file in the first device is improved when the cross-device file is accessed.

In addition, the system application is an authenticated application which is developed inside the first equipment manufacturer, and the credibility is high; in contrast, the third-party application is an application developed by a third-party developer, and the credibility of the application is low, and the embodiment of the application can judge whether the target application program is a trusted application program or not in different ways for the system program or the third-party program according to the target application program, so that whether the target application program is a trusted signature program or not can be judged more reasonably and effectively based on the characteristics of the system program or the third-party program.

if a plurality of unresponsive requests for accessing the target file exist, determining a response sequence between the access requests and other requests; locking the access thread for responding to the access request when the sequence for responding to the access request is not reached; and when the order of responding to the access requests is reached, unlocking the access threads, and responding to the access requests based on the access threads.

In the technical scheme of the application, the operations of acquiring, storing, using, processing, transmitting, providing, disclosing and the like of the personal information of the user are all carried out under the condition that the authorization of the user is obtained.

An embodiment of the present application further provides an electronic device, as shown in fig. 5, which is a schematic structural diagram of the electronic device provided in the embodiment of the present application, where the electronic device includes:

a memory 501 for storing a computer program;

the processor 502 is configured to implement the file access method provided in the embodiment of the present application when executing the program stored in the memory 501.

The electronic device may further include a communication bus and/or a communication interface, and the processor 502, the communication interface, and the memory 501 complete communication with each other through the communication bus.

The communication bus mentioned in the electronic device may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown, but this is not intended to represent only one bus or type of bus.

The communication interface is used for communication between the electronic equipment and other equipment.

The Memory may include a Random Access Memory (RAM) or a Non-Volatile Memory (NVM), such as at least one disk Memory. Optionally, the memory may also be at least one memory device located remotely from the processor.

The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also Digital Signal Processors (DSPs), application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components.

In another embodiment provided by the present application, a computer-readable storage medium is further provided, in which a computer program is stored, and the computer program, when executed by a processor, implements the file access method provided by the embodiment of the present application.

In yet another embodiment provided by the present application, there is also provided a computer program product containing instructions, which when run on a computer, cause the computer to execute the file access method provided by the embodiment of the present application.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk (SSD)), among others.

It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising a … …" does not exclude the presence of another identical element in a process, method, article, or apparatus that comprises the element.

All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on differences from other embodiments. In particular, as for the device, the electronic apparatus, and the storage medium embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, and for the relevant points, reference may be made to the partial description of the method embodiments.

The above description is only for the preferred embodiment of the present application, and is not intended to limit the scope of the present application. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application are included in the protection scope of the present application.

Claims

1. A file access method, applied to a first device, the method comprising:

after receiving an access request for a target file sent by the second device, if the target file is a file allowing a target application program to access, responding to the access request, wherein the target application program is: an application program in the second device requesting access to the target file, where the target file is a file in the first file directory, and the access request is: the target application program generates a request according to the mapping path of the target file in the second file directory;

2. The method of claim 1, wherein determining whether the target application is a trusted signature program is performed by:

obtaining a signature file of the target application from the second device;

3. The method of claim 1, wherein determining whether the target file is a file that the target application is permitted to access is performed by:

4. The method of any of claims 1-3, wherein said responding to the access request comprises:

obtaining a mapping path of the target file under the second file directory;

5. The method of any of claims 1-3, wherein said responding to the access request comprises:

if a plurality of unresponsive requests for accessing the target file exist, determining a response sequence between the access requests and other requests;

locking the access threads used for responding to the access requests when the sequence of responding to the access requests is not reached;

6. A file access apparatus, applied to a first device, the apparatus comprising:

the first access request response module is configured to, after receiving an access request for a target file sent by the second device, respond to the access request if the target file is a file that allows access by a target application program, and otherwise, trigger the second access request response module, where the target application program is: an application program in the second device requesting access to the target file, where the target file is a file in the first file directory, and the access request is: the target application program generates a request according to the mapping path of the target file in the second file directory;

7. The apparatus of claim 6, wherein determining whether the target application is a trusted signature program is performed by:

obtaining a signature file of the target application from the second device; if the target application program is a system program and the signature file has a system tag, determining that the target application program is a trusted signature program; and if the target application program is a third-party program and the signature file is valid, verifying the target application program according to signature information and verification information contained in the signature file, and determining that the target application program is a trusted signature program under the condition that the verification is passed.

8. The apparatus of claim 6, wherein determining whether the target file is a file that the target application is permitted to access is performed by:

9. The apparatus of any of claims 6-8, wherein the responding to the access request comprises:

10. The apparatus of any of claims 6-8, wherein the responding to the access request comprises:

if a plurality of unresponsive requests for accessing the target file exist, determining a response sequence between the access request and other requests; locking the access thread for responding to the access request when the sequence for responding to the access request is not reached; and when the order of responding to the access requests is reached, unlocking the access threads, and responding to the access requests based on the access threads.

11. An electronic device, comprising:

a memory for storing a computer program;

a processor for implementing the method of any one of claims 1 to 5 when executing a program stored in a memory.

12. A computer-readable storage medium, characterized in that a computer program is stored in the computer-readable storage medium, which computer program, when being executed by a processor, carries out the method of any one of claims 1 to 5.