File management method and device, electronic equipment and medium
By querying and verifying the target file in the local database, the target file is obtained from the local or verified compressed package first, which solves the problem of low resource utilization when the application starts, and achieves efficient file management and fast response.
Patent Information
- Application Number
- CN202510773563.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-10
- Publication Date
- 2025-09-05
AI Technical Summary
In the prior art, an application program pre-downloads and initializes all shared object files at the initial startup, resulting in low resource utilization of the user device's storage space.
By querying the target file in the local database and verifying it, the target file is obtained locally first. If it is not found, the compressed package is obtained and verified. After ensuring the integrity of the file, the target file is decompressed and downloaded from the cloud if necessary.
It improves the resource utilization of file management, enhances the processing efficiency and response speed of target applications, and avoids the pre-download of redundant files.
Smart Images
Figure CN120596436A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of artificial intelligence technology, and in particular to a file management method, device, electronic device, and medium. Background Art
[0002] As application functionality becomes increasingly complex, the expansion of application size has become the norm. To implement complex features such as local high-performance computing, graphics rendering, or hardware acceleration, developers often need to integrate a large number of shared object files.
[0003] Currently, many applications adopt a technical strategy of pre-downloading and initializing all necessary shared object files at the initial startup. This forces users to download and store shared object files corresponding to functional modules that may never be used, occupying the user's limited device storage space and resulting in low overall file resource utilization. Summary of the Invention
[0004] The main purpose of the embodiments of the present application is to propose a file management method, device, electronic device and medium, aiming to solve the problem of low resource utilization in existing file management methods.
[0005] To achieve the above objectives, a first aspect of an embodiment of the present application provides a file management method, the method comprising:
[0006] Acquire a user instruction for a target application, where the user instruction is used to instruct the target application to execute a target event;
[0007] In response to the user instruction, query the execution file of the target event in the local database to obtain a first query result;
[0008] If the first query result indicates that a target file corresponding to the target event exists in the local database, verifying the target file in the local database, and obtaining the target file from the local database if the verification passes;
[0009] If the first query result indicates that the target file does not exist in the local database, obtaining a first compressed package containing the target file, verifying the first compressed package, and decompressing the first compressed package to obtain the target file if the verification passes;
[0010] The target application is controlled to execute the target event based on the target file.
[0011] In some embodiments, when the first query result indicates that a target file corresponding to the target event exists in the local database, verifying the target file in the local database, and obtaining the target file from the local database if the verification passes, includes:
[0012] When the first query result indicates that a target file corresponding to the target event exists in the local database, calculating the target file to obtain a first hash value;
[0013] Perform verification according to the first Hash value to obtain a first verification result;
[0014] When the first verification result indicates that the target file passes verification, the target file is obtained from the local database.
[0015] In some implementations, after performing verification according to the first Hash value to obtain a first verification result, the method further includes:
[0016] If the first verification result indicates that the target file fails verification, obtaining a second compressed package containing the target file;
[0017] Decompressing the second compressed package to obtain a first file;
[0018] Perform calculation based on the first file to obtain a second hash value;
[0019] Perform verification according to the second Hash value to obtain a second verification result;
[0020] When the second verification result indicates that the second compressed package passes verification, the target file is obtained from the first file.
[0021] In some embodiments, when the first query result indicates that the target file does not exist in the local database, obtaining a first compressed package containing the target file, verifying the first compressed package, and decompressing the first compressed package to obtain the target file if the verification passes, includes:
[0022] If the first query result indicates that the target file does not exist in the local database, query the local database to obtain a second query result, where the second query result is used to indicate whether the first compressed package exists in the local database;
[0023] If the second query result indicates that the first compressed package exists in the local database, decompress the first compressed package to obtain a second file;
[0024] Calculate the third hash value based on the second file;
[0025] Perform verification according to the third Hash value to obtain a third verification result;
[0026] When the third verification result indicates that the second file passes verification, the target file is obtained from the second file.
[0027] In some embodiments, when the first query result indicates that the target file does not exist in the local database, obtaining a first compressed package containing the target file, verifying the first compressed package, and decompressing the first compressed package to obtain the target file if the verification passes, includes:
[0028] If the first query result indicates that the target file does not exist in the local database, query the local database to obtain a second query result, where the second query result is used to indicate whether the first compressed package exists in the local database;
[0029] If the second query result indicates that the first compressed package exists in the local database, decompress the first compressed package to obtain a second file;
[0030] Calculate the third hash value based on the second file;
[0031] Perform verification according to the third Hash value to obtain a third verification result;
[0032] When the third verification result indicates that the second file passes verification, the target file is obtained from the second file.
[0033] In some embodiments, when the third verification result indicates that the second file has passed verification, obtaining the target file from the second file includes:
[0034] Calculate the target file in the second file to obtain a fifth Hash value;
[0035] Perform verification according to the fifth Hash value to obtain a fifth verification result;
[0036] When the fifth verification result indicates that the target file passes verification, the target file is obtained from the second file.
[0037] In some implementations, after performing verification according to the fourth Hash value to obtain a fourth verification result, the method further includes:
[0038] If the fourth verification result indicates that the third file fails verification, responding to a user's instruction to re-download;
[0039] Downloading a third compressed package from the cloud, wherein the third compressed package includes the target file;
[0040] Decompressing the three compressed packages to obtain a fourth file;
[0041] Calculating according to the fourth file to obtain a sixth hash value;
[0042] Perform verification according to the sixth Hash value to obtain a sixth verification result;
[0043] When the sixth verification result indicates that the fourth file passes verification, the target file is obtained from the fourth file.
[0044] To achieve the above-mentioned purpose, a second aspect of an embodiment of the present application provides a file management device, the device comprising:
[0045] An instruction acquisition module, configured to acquire a user instruction for a target application, wherein the user instruction is used to instruct the target application to execute a target event;
[0046] A file query module, configured to, in response to the user instruction, perform file query processing in a local database based on the target event to obtain a first query result;
[0047] a first acquisition module, configured to, when the first query result indicates that a target file corresponding to the target event exists in the local database, verify the target file in the local database, and acquire the target file from the local database if the verification passes;
[0048] a second acquisition module configured to, if the first query result indicates that the target file does not exist in the local database, acquire a first compressed package containing the target file, verify the first compressed package, and decompress the first compressed package to obtain the target file if the verification passes;
[0049] An instruction execution module is used to control the target application to execute the target event based on the target file.
[0050] To achieve the above-mentioned purpose, the third aspect of an embodiment of the present application proposes an electronic device, which includes a memory and a processor, the memory stores a computer program, and the processor implements the file management method described in the first aspect when executing the computer program.
[0051] To achieve the above objectives, the fourth aspect of the embodiments of the present application proposes a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the file management method described in the first aspect.
[0052] To achieve the above objectives, an embodiment of the present application may provide a computer program product for implementation. When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device implements the file management method described in the first aspect above.
[0053] The file management method, device, electronic device and medium proposed in this application achieve rapid response and efficient processing of user instructions by preferentially querying the target file in the local database; when the target file exists locally and passes the verification, it can be immediately obtained and executed, significantly improving the efficiency and response speed of the target application in processing the target event; when the target file does not exist in the local database, the required file is obtained by verifying the external compressed package, ensuring the ultimate executableness of the target event, avoiding the effect of pre-downloading redundant files, and thus improving the resource utilization of file management. BRIEF DESCRIPTION OF THE DRAWINGS
[0054] Figure 1 This is a flowchart of a file management method provided by an embodiment of the present application;
[0055] Figure 2 yes Figure 1 Flow chart of step S103 in FIG.
[0056] Figure 3 yes Figure 1 Flow chart of step S104 in FIG.
[0057] Figure 4 yes Figure 3 Flow chart of step S405 in FIG.
[0058] Figure 5 This is a schematic diagram of the structure of the file management device provided in an embodiment of the present application;
[0059] Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0060] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.
[0061] It should be noted that although the device schematics illustrate functional module divisions and the flowcharts illustrate logical sequences, in certain circumstances, the steps shown or described may be performed in a sequence that differs from the module divisions in the device or the sequence in the flowcharts. The terms "first," "second," and so on, in the specification, claims, and drawings, are used to distinguish similar items and are not necessarily used to describe a specific sequence or precedence.
[0062] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.
[0063] As application functionality becomes increasingly complex, the expansion of application size has become the norm. To implement complex features such as local high-performance computing, graphics rendering, or hardware acceleration, developers often need to integrate a large number of shared object files.
[0064] Currently, many applications adopt a technical strategy of pre-downloading and initializing all necessary shared object files at the initial startup. This forces users to download and store shared object files corresponding to functional modules that may never be used, occupying the user's limited device storage space and resulting in low overall file resource utilization.
[0065] Based on this, the embodiments of the present application provide a file management method, device, electronic device and medium, aiming to solve the problem of low resource utilization in existing file management methods.
[0066] The file management method, device, electronic device, and medium provided in the embodiments of the present application are specifically described through the following embodiments. First, the file management method in the embodiments of the present application is described.
[0067] The embodiments of the present application can acquire and process relevant data based on artificial intelligence technology. Artificial Intelligence (AI) is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use knowledge to achieve optimal results.
[0068] Fundamental AI technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interaction systems, and mechatronics. AI software technologies primarily encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.
[0069] The file management method provided in the embodiment of the present application relates to the field of artificial intelligence and can be applied to business fields such as financial technology and medical health. The file management method provided in the embodiment of the present application can be applied to a terminal, can be applied to a server side, and can also be software running in a terminal or a server side. In some embodiments, the terminal can be a smart phone, a tablet computer, a laptop computer, a desktop computer, etc.; the server side can be configured as an independent physical server, or as a server cluster or distributed system composed of multiple physical servers, or as a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application that implements the file management method, etc., but is not limited to the above forms.
[0070] The present application can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. The present application can also be practiced in distributed computing environments in which tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media, including storage devices.
[0071] It should be noted that in each specific embodiment of this application, when it comes to the need to perform relevant processing based on information, behavioral data, historical data, location information, and other data related to identity or characteristics, permission or consent must be obtained first, and the collection, use, and processing of such data must comply with relevant laws, regulations, and standards. In addition, when the embodiment of this application needs to obtain sensitive personal information, a separate permission or separate consent will be obtained through a pop-up window or by jumping to a confirmation page. After the separate permission or separate consent is clearly obtained, the necessary relevant data for the normal operation of the embodiment of this application will be obtained.
[0072] Figure 1 This is a flowchart of the file management method provided by the embodiment of the present application. Figure 1 The file management method provided in the embodiment of the present application may include but is not limited to steps S101 to S105.
[0073] Step S101: Obtain a user instruction for a target application, where the user instruction is used to instruct the target application to execute a target event.
[0074] In this step, the target application refers to the application that executes the user instruction.
[0075] User commands refer to interactive signals that trigger specific functional operations. They can be implemented through touch commands, voice commands, or preset shortcut operations to accurately capture the user's current functional needs.
[0076] A target event is a specific action that a user instruction instructs the target application to complete.
[0077] For example, in a mobile banking app in the financial and insurance industry, a user clicks the "Transfer" button and enters the payee account number and amount to confirm the initiation of a transfer operation, where the target application is the mobile banking app and the target event is to execute the operation of transferring a specified amount to a specified account.
[0078] In a health management app in the medical and health management industry, a user says "Generate health report" to the chatbot provided by the health management app, requesting to view a comprehensive analysis report based on his or her historical health data. The target application is the health management app, and the target event is to generate and display the user's comprehensive health report.
[0079] Step S102: In response to the user instruction, query the execution file in the local database based on the target event to obtain a first query result.
[0080] In this step, the local database refers to a local storage unit that stores downloaded files and their metadata, and can be implemented using a SQLite relational database or a key-value pair storage structure to quickly retrieve existing files to avoid repeated downloading.
[0081] Specifically, when a user triggers a function that requires support from a specific shared object file, based on the execution file of the target event, the target file corresponding to the target event is queried in the local storage to obtain a first query result. The first query result is used to indicate whether the target file corresponding to the target event is found in the local database.
[0082] For example, in a mobile banking app in the financial and insurance industry, a user clicks the "Transfer" button and enters the payee account number and amount to confirm the initiation of a transfer operation. The target event is identified as an operation to transfer a specified amount to a specified account. The execution file information related to the transfer function is queried in the local database to obtain the first query result.
[0083] In a health management app in the medical and health management industry, a user says "Generate today's exercise report" to the chatbot provided by the health management app, which identifies the target event as generating an exercise report, searches the local database for an executable file related to the function of generating an exercise report, and obtains a first query result.
[0084] Step S103: If the first query result indicates that a target file corresponding to the target event exists in the local database, verify the target file in the local database, and obtain the target file from the local database if the verification passes.
[0085] In this step, the verification process refers to a security mechanism for verifying the integrity of the file, which can be specifically achieved by hash value comparison or digital signature verification to ensure that the obtained file has not been tampered with.
[0086] Specifically, if the target file exists in the local database and the target file in the local database passes verification, the target file is directly called from the local database to avoid delays caused by network requests.
[0087] For example, in a mobile banking app in the financial insurance industry, it is found that a target file is stored under path A in the local database. The target file is verified, and then the target file is directly retrieved from the local database through path A after the verification passes.
[0088] Step S104: When the first query result indicates that the target file does not exist in the local database, obtain a first compressed package containing the target file, verify the first compressed package, and decompress the target file from the first compressed package if the verification passes.
[0089] In this step, the compressed package refers to a packaging format containing multiple associated files, and specifically a ZIP, RAR or 7z compression algorithm can be used to reduce the amount of network transmission data and maintain file association.
[0090] Specifically, when the target file is missing from the local database, a compressed package containing the target file is obtained, and the compressed package is decompressed and verified. When the compressed package passes the verification, the target file is decompressed from the compressed package.
[0091] It should be noted that the compressed package may be stored in a local database or in a cloud server.
[0092] For example, in a health management app in the medical and health management industry, if no target file is found stored in the local database, a first compressed package containing the target file is obtained from the local database, the first compressed package is decompressed and verified, and after the verification is passed, the target file is extracted from the file decompressed from the first compressed package, and the target file is stored in the corresponding file directory.
[0093] In the health management app of the medical and health management industry, if no target file is found to be stored in the local database, a first compressed package containing the target file is obtained from the cloud server, the first compressed package is decompressed and verified, and after the verification is passed, the target file is extracted from the file decompressed from the first compressed package and the target file is stored in the local database.
[0094] Step S105: Control the target application to execute the target event based on the target file.
[0095] In this step, the target application is controlled by the target file to execute the target event corresponding to the user instruction.
[0096] In this implementation, rapid response and efficient processing of user instructions are achieved by preferentially querying the target file in the local database; when the target file exists locally and passes verification, it can be immediately obtained and executed, significantly improving the efficiency and response speed of the target application in processing target events; when the target file does not exist in the local database, the required file is obtained by verifying the external compressed package, ensuring the ultimate executableness of the target event, avoiding the effect of pre-downloading redundant files, and thus improving the resource utilization of file management.
[0097] In some embodiments, as Figure 2 As shown, in step S103, when the first query result indicates that a target file corresponding to the target event exists in the local database, the target file in the local database is verified, and when the verification passes, the target file is obtained from the local database, which may include but is not limited to steps S201 to S203.
[0098] Step S201: When the first query result indicates that a target file corresponding to the target event exists in the local database, the target file is calculated to obtain a first hash value.
[0099] Step S202: Perform verification according to the first Hash value to obtain a first verification result.
[0100] Step S203: When the first verification result indicates that the target file has passed verification, the target file is obtained from the local database.
[0101] In this implementation, the first hash value refers to a fixed-length character string generated by performing a one-way calculation on the target file through a hash algorithm, which can be specifically implemented using the SHA-256 or MD5 algorithm, and is used to uniquely identify the content integrity of the target file.
[0102] Hash value verification refers to comparing the calculated hash value with the preset standard hash value. If they are consistent, it is determined that the file has not been tampered with or damaged, thereby verifying the reliability of the target file.
[0103] Specifically, when an application needs to execute a target event, if the target file already exists in the local database, a hash algorithm is used to generate a unique hash value for the target file. For example, if the target file is a shared object file required for graphics rendering, the system calculates its MD5 hash value and compares it with the pre-stored correct hash value. If the comparison results are consistent, it indicates that the target file has not been modified or damaged and can be directly called from the local database. If they are inconsistent, the subsequent process of obtaining a compressed package or downloading it from the cloud is triggered, thus avoiding functional anomalies caused by using the wrong file.
[0104] It should be noted that the preset reference hash value is an original, untampered hash value pre-stored for the target file.
[0105] For example, in the financial insurance industry, a user submits a claim application through the insurance company's claims app. The claims app obtains the insurance terms file related to the claim event to assist in claim processing. After the claims app queries the insurance terms file corresponding to the claim event in the local database, it uses the MD5 algorithm to calculate this file to obtain a first hash value. If the standard hash value of the insurance terms file stored in the local database is "abc123def456", and the calculated first hash value is also "abc123def456", the first verification result indicates that the target file verification has passed. If the verification passes, the claims app obtains the insurance terms file from the local database.
[0106] In this implementation, the reliability of the target file is ensured through a hash verification mechanism, which reduces the risk of application execution failure caused by file errors and optimizes the efficiency of the resource acquisition process.
[0107] In some implementations, after verifying the first hash value in step S202 to obtain a first verification result, the file management method provided in the embodiment of the present application further includes but is not limited to steps S301 to S305.
[0108] Step S301: When the first verification result indicates that the target file fails verification, obtain a second compressed package containing the target file.
[0109] Step S302: decompress the second compressed package to obtain a first file.
[0110] Step S303: Calculate according to the first file to obtain a second hash value.
[0111] Step S304: Perform verification according to the second Hash value to obtain a second verification result.
[0112] Step S305: When the second verification result indicates that the second compressed package passes verification, obtain the target file from the first file.
[0113] In this implementation, the second compressed package refers to a compressed data package containing the target file, and can be implemented in a compression format such as ZIP or RAR.
[0114] The first file refers to a set of files decompressed from the second compressed package, which is specifically achieved through a decompression algorithm.
[0115] The second hash value refers to a verification code generated based on the content of the first file, and is specifically implemented using a hash algorithm such as SHA-256 or MD5.
[0116] Specifically, when the target file in the local database fails verification due to data corruption or version errors, the system automatically obtains a second compressed package as a backup resource. After decompressing the compressed package to generate the first file, the system calculates the hash value of the first file using a hash algorithm such as SHA-256 or MD5 to obtain the second hash value, which is then compared with the pre-stored correct hash value for verification. If the verification passes, the target file is extracted from the first file; if it fails, the operation is terminated.
[0117] For example, in the financial insurance industry, if the insurance clause file in the local database fails to pass the verification, the claim app will obtain a second compressed package containing the insurance clause file from the local database or the insurance company's server. For example, the compressed package is named "InsurancePolicyFiles.zip", which contains multiple files related to claims, including the insurance clause file required by the user; the second compressed package is decompressed to obtain the first file, and the hash value of the first file is calculated to obtain the second hash value. If the standard hash value of the first file stored in the local database or the insurance company's server is "efg456hij789", and the calculated second hash value is also "efg456hij789", then the second verification result indicates that the target file has passed the verification. If the verification passes, the claim app obtains the insurance clause file from the first file.
[0118] In this implementation, by reusing locally stored compressed resources, the dependence on external networks is reduced while ensuring file integrity, resource acquisition efficiency is improved, and the problem of repeatedly downloading file compression packages and occupying device memory is avoided.
[0119] In some embodiments, as Figure 3 As shown, in step S104, if the first query result indicates that the target file does not exist in the local database, a first compressed package containing the target file is obtained, the first compressed package is verified, and if the verification passes, the target file is decompressed from the first compressed package, which may include but is not limited to steps S401 to S405.
[0120] Step S401: When the first query result indicates that the target file does not exist in the local database, a query is performed in the local database to obtain a second query result, where the second query result is used to indicate whether the first compressed package exists in the local database.
[0121] Step S402: When the second query result indicates that the first compressed package exists in the local database, decompress the first compressed package to obtain a second file.
[0122] Step S403: Calculate according to the second file to obtain a third hash value.
[0123] Step S404: perform verification according to the third Hash value to obtain a third verification result.
[0124] Step S405: When the third verification result indicates that the second file has passed verification, obtain the target file from the second file.
[0125] In this implementation, the local database refers to a local storage space for storing compressed package files, and can be implemented using an embedded database or a file system directory structure.
[0126] The first compressed package refers to an archive file containing the target file, and can be implemented in ZIP or TAR format.
[0127] The second file refers to a decompressed file set, which may specifically include multiple sub-files or a directory structure.
[0128] The third hash value refers to a checksum calculated from the decompressed second file using a hash algorithm, which may be implemented using the SHA-256 or MD5 algorithm.
[0129] The third verification result refers to the result of comparing the calculated hash value with the preset value. If they match, it indicates that the file has not been tampered with or damaged.
[0130] Specifically, when the target application needs to execute the target event according to user instructions, if the corresponding target file does not exist in the local database, it is prioritized to check whether a compressed package containing the target file has been stored locally; for example, the local database may have pre-cached a compressed package downloaded historically; if so, a decompression operation is performed to generate a second file, and a hash value is calculated for the decompressed file to perform an integrity check; if the check passes, it indicates that the contents of the compressed package are not damaged, and the target file can be directly extracted from it for event execution.
[0131] For example, in the healthcare industry, a doctor views a patient's medical records through an electronic medical record app, but no medical record file related to the patient is found in the local database. The doctor further queries the local database to see whether a first compressed package containing the file exists, and obtains a second query result. When the second query result indicates that the first compressed package exists in the local database, the first compressed package is decompressed to obtain a second file, the hash value of the second file is calculated and verified, and after the verification is passed, the medical record file related to the patient is obtained from the second file.
[0132] In this implementation, redundant compressed package resources stored locally are effectively utilized, local data is reused preferentially while ensuring file integrity, the number of unnecessary network requests is reduced, the load pressure on the cloud server is reduced, and the response time of the file acquisition path is shortened.
[0133] In some embodiments, in step S104, if the first query result indicates that the target file does not exist in the local database, a first compressed package containing the target file is obtained, the first compressed package is verified, and if the verification passes, the target file is decompressed from the first compressed package, which may include but is not limited to steps S501 to S505.
[0134] Step S501: When the second query result indicates that the first compressed package does not exist in the local database, or the third verification result indicates that the second file verification fails, download the first compressed package from the cloud.
[0135] Step S502: decompress the first compressed package to obtain a third file.
[0136] Step S503: Calculate according to the third file to obtain a fourth Hash value.
[0137] Step S504: perform verification according to the fourth Hash value to obtain a fourth verification result.
[0138] Step S505: When the fourth verification result indicates that the third file has passed verification, obtain the target file from the third file.
[0139] In this implementation, cloud download refers to the process of obtaining a compressed file from a remote server via the network, which can be implemented using HTTP or FTP protocols to obtain the required file from external resources when local resources are unavailable.
[0140] Decompression refers to the operation of restoring data in a compressed package. It can be implemented by using ZIP or RAR decompression algorithms to release the original file contents in the compressed package.
[0141] Hash value calculation refers to the process of mapping file content to a fixed-length string through a hash function. Specifically, it can be implemented using the SHA-256 or MD5 algorithm to generate a unique identifier to verify file integrity.
[0142] Verification refers to the process of comparing the calculated hash value with the preset standard hash value. It can be implemented by using a digital signature or checksum matching mechanism to determine whether the file has been tampered with or damaged.
[0143] Specifically, when the local database does not contain the original file corresponding to the target file and the valid file cannot be obtained through the existing compressed package, the cloud download process is automatically triggered; after the compressed package is downloaded locally, a third file is generated through decompression, and a hash value is generated for verification. After the verification is passed, the target file is obtained from the third file.
[0144] For example, in the healthcare industry, a doctor clicks a button in an electronic medical record app to view a patient's medical record, but no medical record file related to the patient is found in the local database, and a compressed package containing the file does not exist in the local database, or the file decompressed from the local database fails verification. In this case, the doctor downloads a first compressed package containing the file from the hospital's cloud server, decompresses the first compressed package to obtain a third file, calculates the hash value of the third file and verifies it, and obtains the medical record file related to the patient from the third file after verification.
[0145] In this implementation, the minimum necessary file set is obtained from the cloud on demand only when local resources are missing or verification fails, and a phased verification mechanism is used to ensure data reliability, avoid persistent storage of invalid files, and effectively reduce the occupancy of device storage space.
[0146] In some embodiments, as Figure 4 As shown, in step S405, when the third verification result indicates that the second file has passed verification, obtaining the target file from the second file may include but is not limited to steps S601 to S603.
[0147] Step S601: Calculate the target file in the second file to obtain a fifth Hash value.
[0148] Step S602: Perform verification according to the fifth Hash value to obtain a fifth verification result.
[0149] Step S603: When the fifth verification result indicates that the target file has passed verification, obtain the target file from the second file.
[0150] In this implementation, the fifth hash value refers to a unique identifier obtained by performing a hash operation on the target file, which can be implemented using the SHA-256 or MD5 algorithm to verify the integrity and tamper-free status of the target file.
[0151] The fifth verification result refers to determining whether the target file meets the expected verification conclusion by comparing the fifth hash value with the preset standard hash value. Specifically, a hash value matching algorithm can be used to ensure the validity of the target file after decompression.
[0152] Specifically, after the second file is decompressed, the target file is extracted separately and its hash value is calculated to obtain a fifth hash value. The integrity of the target file is verified by matching the hash values. If the verification passes, the target file is retrieved and used for subsequent event execution. For example, if the first compressed package exists in the local database, after the second file is decompressed, the target file is further independently verified to ensure that it has not been damaged or tampered with during transmission or storage.
[0153] In this implementation, after the compressed package is verified, the target file is further independently hashed to avoid execution failures caused by partial damage to the compressed package or errors in the file content, ensuring the availability and reliability of the target file, while reducing the problems of repeated downloads or redundant storage caused by file errors.
[0154] In other implementations, in step S405, when the third verification result indicates that the second file has passed verification, the target file is obtained from the second file, and the method of steps S601 to S603 above can also be used for verification and acquisition to ensure that the target file is not damaged or tampered with during the decompression and transmission process.
[0155] In some implementations, after the verification is performed according to the fourth hash value in step S504 to obtain a fourth verification result, the file management method provided in the embodiment of the present application further includes but is not limited to steps S701 to S706.
[0156] Step S701: When the fourth verification result indicates that the third file verification fails, respond to the user's instruction to re-download.
[0157] Step S702: Download a third compressed package from the cloud, wherein the third compressed package includes the target file.
[0158] Step S703: decompress the three compressed packages to obtain a fourth file.
[0159] Step S704: Calculate according to the fourth file to obtain a sixth hash value.
[0160] Step S705: Perform verification according to the sixth Hash value to obtain a sixth verification result.
[0161] Step S706: When the sixth verification result indicates that the fourth file has passed verification, obtain the target file from the fourth file.
[0162] In this implementation, the fourth verification result refers to the conclusion of the integrity verification of the third file obtained by decompressing the first compressed package downloaded from the cloud. It can be specifically implemented using a hash value matching algorithm to determine whether the file has been tampered with or damaged during transmission or storage.
[0163] The user re-download instruction refers to a data retransmission operation actively triggered by the user, which can be implemented through a graphical interface button or voice command, and is used to initiate a secondary download request when file verification fails.
[0164] The third compressed package refers to a compressed data set containing the target file stored in the cloud server, which can be packaged in ZIP or RAR format to reduce the amount of data transmitted over the network.
[0165] The sixth hash value refers to a fixed-length character string generated by calculating the content of the fourth file, and can be specifically implemented using the SHA-256 or MD5 algorithm to verify file integrity.
[0166] Specifically, when the third file obtained after decompressing the first compressed package downloaded from the cloud fails the fourth verification result due to a network transmission error or storage medium failure, the user will be prompted with a pop-up window on the target application interface to indicate the download failure, waiting for the user to actively trigger the re-download instruction.
[0167] After the user issues an instruction through the interactive interface, it will reconnect to the cloud server and download the third compressed package, which may contain an updated version or a redundant backup target file; after the download is complete, the compressed package is decompressed to generate a fourth file, and its corresponding sixth hash value is calculated. By comparing the sixth hash value with the preset reference value, if they match, the sixth verification result is determined to be passed, and the target file is extracted from the fourth file for the target application to call.
[0168] In this implementation, by introducing an interactive mechanism for user re-download instructions, users are allowed to independently decide whether to initiate a second download in specific scenarios. Combined with the multiple hash verification process, invalid circular download behavior can be effectively avoided, while improving the accuracy of file recovery, so as to achieve a balanced optimization of the utilization efficiency of storage resources and computing resources.
[0169] Figure 5 This is a schematic diagram of the structure of the file management device provided in the embodiment of the present application. Figure 5 The present application also provides a file management device 800 that can implement the above-mentioned file management method. The file management device 800 includes:
[0170] An instruction acquisition module 801 is used to acquire a user instruction for a target application, wherein the user instruction is used to instruct the target application to execute a target event;
[0171] A file query module 802 is configured to, in response to the user instruction, perform file query processing in a local database based on the target event to obtain a first query result;
[0172] A first acquisition module 803 is configured to, when the first query result indicates that a target file corresponding to the target event exists in the local database, verify the target file in the local database, and obtain the target file from the local database if the verification passes;
[0173] A second acquisition module 804 is configured to, if the first query result indicates that the target file does not exist in the local database, acquire a first compressed package containing the target file, verify the first compressed package, and decompress the first compressed package to obtain the target file if the verification passes;
[0174] The instruction execution module 805 is configured to control the target application to execute the target event based on the target file.
[0175] In some implementations, the first acquisition module 803 includes:
[0176] a first calculation submodule, configured to, when the first query result indicates that a target file corresponding to the target event exists in the local database, calculate the target file to obtain a first hash value;
[0177] A first check submodule, configured to perform a check based on the first Hash value to obtain a first check result;
[0178] The first acquisition submodule is configured to acquire the target file from the local database if the first verification result indicates that the target file has passed verification.
[0179] In some implementations, the first acquisition module 803 further includes:
[0180] A second acquisition submodule is configured to acquire a second compressed package containing the target file if the first verification result indicates that the target file fails verification;
[0181] A first decompression submodule, configured to decompress the second compressed package to obtain a first file;
[0182] A second calculation submodule, configured to perform calculation based on the first file to obtain a second hash value;
[0183] A second check submodule, configured to perform a check based on the second Hash value to obtain a second check result;
[0184] The third acquisition submodule is used to obtain the target file from the first file when the second verification result indicates that the second compressed package has passed verification.
[0185] In some implementations, the second acquisition module 804 includes:
[0186] a first query submodule configured to, if the first query result indicates that the target file is not found in the local database, perform a query in the local database to obtain a second query result, wherein the second query result is used to indicate whether the first compressed package exists in the local database;
[0187] a second decompression submodule, configured to decompress the first compressed package to obtain a second file if the second query result indicates that the first compressed package exists in the local database;
[0188] A third calculation submodule, configured to perform calculation according to the second file to obtain a third hash value;
[0189] A third check submodule, configured to perform a check based on the third Hash value to obtain a third check result;
[0190] The fourth acquisition submodule is used to acquire the target file from the second file if the third verification result indicates that the second file has passed verification.
[0191] In some implementations, the second acquisition module 804 further includes:
[0192] A first download submodule is configured to download the first compressed package from the cloud if the second query result indicates that the first compressed package does not exist in the local database, or if the third verification result indicates that the second file verification fails;
[0193] A third decompression submodule, configured to decompress the first compressed package to obtain a third file;
[0194] a fourth calculation submodule, configured to perform calculation according to the third file to obtain a fourth hash value;
[0195] a fourth check submodule, configured to perform a check based on the fourth Hash value to obtain a fourth check result;
[0196] The fifth acquisition submodule is configured to acquire the target file from the third file if the fourth verification result indicates that the third file has passed verification.
[0197] In some embodiments, the fourth acquisition submodule includes:
[0198] A first calculation unit, configured to calculate a target file in the second file to obtain a fifth hash value;
[0199] a first verification unit, configured to perform verification according to the fifth Hash value to obtain a fifth verification result;
[0200] The first acquiring unit is configured to acquire the target file from the second file if the fifth verification result indicates that the target file has passed verification.
[0201] In some implementations, the second acquisition module 804 further includes:
[0202] A first response submodule, configured to respond to a user's instruction to re-download if the fourth verification result indicates that the third file fails verification;
[0203] A second download submodule is configured to download a third compressed package from the cloud, wherein the third compressed package includes the target file;
[0204] A fourth decompression submodule, configured to decompress the three compressed packages to obtain a fourth file;
[0205] a fifth calculation submodule, configured to perform calculation according to the fourth file to obtain a sixth hash value;
[0206] a fifth check submodule, configured to perform a check based on the sixth Hash value to obtain a sixth check result;
[0207] The sixth acquisition submodule is configured to acquire the target file from the fourth file if the sixth verification result indicates that the fourth file has passed verification.
[0208] The specific implementation of the file management device 800 is basically the same as the specific embodiment of the above-mentioned file management method, and will not be repeated here.
[0209] The present application also provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the above-mentioned file management method when executing the computer program. The electronic device can be any intelligent terminal including a desktop computer, a tablet computer, a mobile phone, and an in-vehicle computer.
[0210] See also Figure 6 , Figure 6 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application. The electronic device includes:
[0211] The processor 901 can be implemented as a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.
[0212] The memory 902 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 902 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called by the processor 901 to execute the file management method of the embodiments of this application.
[0213] Input / output interface 903, used to implement information input and output;
[0214] Communication interface 904, used to implement communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WiFi, Bluetooth, etc.);
[0215] Bus 905 , which transmits information between various components of the device (e.g., processor 901 , memory 902 , input / output interface 903 , and communication interface 904 );
[0216] The processor 901 , the memory 902 , the input / output interface 903 and the communication interface 904 are connected to each other in communication within the device via a bus 905 .
[0217] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the above-mentioned file management method is implemented.
[0218] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely arranged relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.
[0219] In addition, the embodiments of the present application may be implemented by providing a computer program product. When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device implements the file management method in the above embodiment.
[0220] The file management method, device, electronic device and medium provided in the embodiments of the present application achieve rapid response and efficient processing of user instructions by preferentially querying the target file in the local database; when the target file exists locally and passes the verification, it can be immediately obtained and executed, significantly improving the efficiency and response speed of the target application in processing the target event; when the target file does not exist in the local database, the required file is obtained by verifying the external compressed package, ensuring the ultimate executableness of the target event, avoiding the effect of pre-downloading redundant files, and thus improving the resource utilization of file management.
[0221] The embodiments described in the embodiments of this application are intended to more clearly illustrate the technical solutions of the embodiments of this application and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.
[0222] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.
[0223] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, i.e., they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.
[0224] Those skilled in the art will appreciate that all or some of the steps in the methods, systems, and functional modules / units in the devices disclosed above may be implemented as software, firmware, hardware, or appropriate combinations thereof.
[0225] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0226] It should be understood that in this application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.
[0227] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the above-mentioned units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
[0228] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0229] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.
[0230] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes multiple instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: various media that can store programs, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.
[0231] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but are not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and essence of the present invention should be within the scope of the present invention.
Claims
1. A file management method, characterized in that: The method comprises: Acquire a user instruction for a target application, where the user instruction is used to instruct the target application to execute a target event; In response to the user instruction, query the execution file of the target event in the local database to obtain a first query result; If the first query result indicates that a target file corresponding to the target event exists in the local database, verifying the target file in the local database, and obtaining the target file from the local database if the verification passes; If the first query result indicates that the target file does not exist in the local database, obtaining a first compressed package containing the target file, verifying the first compressed package, and decompressing the first compressed package to obtain the target file if the verification passes; The target application is controlled to execute the target event based on the target file.
2. The method according to claim 1, characterized in that When the first query result indicates that a target file corresponding to the target event exists in the local database, verifying the target file in the local database, and obtaining the target file from the local database if the verification passes, includes: When the first query result indicates that a target file corresponding to the target event exists in the local database, calculating the target file to obtain a first hash value; Perform verification according to the first Hash value to obtain a first verification result; When the first verification result indicates that the target file passes verification, the target file is obtained from the local database.
3. The method according to claim 2, characterized in that After performing verification according to the first Hash value to obtain a first verification result, the method further includes: If the first verification result indicates that the target file fails verification, obtaining a second compressed package containing the target file; Decompressing the second compressed package to obtain a first file; Perform calculation based on the first file to obtain a second hash value; Perform verification according to the second Hash value to obtain a second verification result; When the second verification result indicates that the second compressed package passes verification, the target file is obtained from the first file.
4. The method according to claim 1, wherein The method further comprises: obtaining a first compressed package containing the target file when the first query result indicates that the target file does not exist in the local database, verifying the first compressed package, and decompressing the first compressed package to obtain the target file when the verification passes, including: If the first query result indicates that the target file does not exist in the local database, query the local database to obtain a second query result, where the second query result is used to indicate whether the first compressed package exists in the local database; If the second query result indicates that the first compressed package exists in the local database, decompress the first compressed package to obtain a second file; Calculate the third hash value based on the second file; Perform verification according to the third Hash value to obtain a third verification result; When the third verification result indicates that the second file passes verification, the target file is obtained from the second file.
5. The method according to claim 4, characterized in that The method further comprises: obtaining a first compressed package containing the target file when the first query result indicates that the target file does not exist in the local database, verifying the first compressed package, and decompressing the first compressed package to obtain the target file when the verification passes, including: If the second query result indicates that the first compressed package does not exist in the local database, or if the third verification result indicates that the second file verification fails, downloading the first compressed package from the cloud; Decompressing the first compressed package to obtain a third file; Performing calculation based on the third file to obtain a fourth hash value; Perform verification according to the fourth Hash value to obtain a fourth verification result; When the fourth verification result indicates that the third file has passed verification, the target file is obtained from the third file.
6. The method according to claim 4, characterized in that When the third verification result indicates that the second file has passed verification, obtaining the target file from the second file includes: Calculate the target file in the second file to obtain a fifth Hash value; Perform verification according to the fifth Hash value to obtain a fifth verification result; When the fifth verification result indicates that the target file passes verification, the target file is obtained from the second file.
7. The method according to claim 5, characterized in that After performing verification according to the fourth Hash value to obtain a fourth verification result, the method further includes: If the fourth verification result indicates that the third file fails verification, responding to a user's instruction to re-download; Downloading a third compressed package from the cloud, wherein the third compressed package includes the target file; Decompressing the three compressed packages to obtain a fourth file; Calculating according to the fourth file to obtain a sixth hash value; Perform verification according to the sixth Hash value to obtain a sixth verification result; When the sixth verification result indicates that the fourth file passes verification, the target file is obtained from the fourth file.
8. A file management device, characterized in that: The device comprises: An instruction acquisition module, configured to acquire a user instruction for a target application, wherein the user instruction is used to instruct the target application to execute a target event; A file query module, configured to, in response to the user instruction, perform file query processing in a local database based on the target event to obtain a first query result; a first acquisition module, configured to, when the first query result indicates that a target file corresponding to the target event exists in the local database, verify the target file in the local database, and acquire the target file from the local database if the verification passes; a second acquisition module configured to, if the first query result indicates that the target file does not exist in the local database, acquire a first compressed package containing the target file, verify the first compressed package, and decompress the first compressed package to obtain the target file if the verification passes; An instruction execution module is used to control the target application to execute the target event based on the target file.
9. An electronic device, characterized in that: The electronic device includes a memory and a processor, the memory stores a computer program, and the processor implements the file management method according to any one of claims 1 to 7 when executing the computer program.
10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the file management method according to any one of claims 1 to 7 is implemented.