Cross-device file operation method, device, medium and product based on open source honkong system

Abstract

The application discloses a cross-device file operation method, device, medium and product based on an open-source MEC system, and the method comprises the following steps: whenever a standard file operation instruction for a target second device is detected, a target file operation record is created, written into a main storage area, and a record temporary storage area is emptied; the standard file operation instruction is executed through a distributed file system, and after the execution, a corresponding record in the main storage area is updated; when an operation rollback instruction is detected, according to a rollback type of the operation rollback instruction, the latest historical file operation record in the main storage area is transferred to the record temporary storage area, or the latest record in the record temporary storage area is transferred to the main storage area; according to the rollback type and the transferred record, a rollback file operation instruction is determined, and the rollback file operation instruction is executed through the distributed file system, and the technical scheme of the embodiment of the application can significantly improve the operation fault tolerance and user experience of the distributed file management.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a cross-device file operation method, device, medium, and product based on the open-source HarmonyOS system. Background Technology

[0002] With the popularization and maturity of distributed operating systems such as OpenHarmony, multi-device collaboration has become the core of intelligent experiences across all scenarios. Within this ecosystem, users frequently need to perform collaborative operations such as moving, copying, deleting, and renaming shared files across multiple networked devices, including mobile phones, tablets, and computers. If such operations result in accidental touches or errors, users urgently need a system-level, reliable, and responsive remediation mechanism to revert to the previous state. This presents a pressing need to ensure data security, improve operational fault tolerance, and enhance the multi-device collaborative experience.

[0003] In existing technologies, cross-device operation history backtracking mainly relies on two types of methods: one is a single-machine record extension scheme, whose asynchronous synchronization mechanism is prone to state conflicts when the device is offline and has difficulty handling cross-device path mapping; the other is a centralized service scheme, which, although enhancing consistency, introduces network latency and single-point dependencies, contradicting the communication advantages of distributed architecture. Neither of these approaches effectively integrates the system's native distributed metadata synchronization and point-to-point communication capabilities, making it difficult to achieve a low-latency, highly consistent operation backtracking experience. Summary of the Invention

[0004] This invention provides a method, device, medium, and product for cross-device file operations based on the open-source HarmonyOS system, to achieve reliable, low-latency undo and redo functions for cross-device file operations.

[0005] According to one aspect of the present invention, a cross-device file operation method based on the open-source HarmonyOS system is provided, which is executed by a file management service running on the open-source HarmonyOS system of a first device, wherein the first device is pre-networked with multiple second devices that have the open-source HarmonyOS system installed, and the method includes: Whenever a standard file operation command for the target second device is detected, a target file operation record for the standard file operation command is created, and the record temporary storage area is cleared while the target file operation record is written to the main storage area. The system executes standard file operation instructions through the distributed file system in the open-source HarmonyOS system, and updates the contents of the target file operation record in the main storage area after the standard file operation instructions are executed. Whenever an operation rollback instruction is detected, depending on the rollback type of the operation rollback instruction, either retrieve the most recently stored historical file operation record from the main storage area and transfer it to the record temporary storage area, or retrieve the most recently stored historical file operation record from the record temporary storage area and transfer it to the main storage area. Based on the backtracking type and the transferred historical file operation records, the backtracking file operation instructions are determined and executed through the distributed file system in the open-source HarmonyOS system.

[0006] According to another aspect of the present invention, a cross-device file operation apparatus based on the open-source HarmonyOS system is provided, which is executed by a file management service running on the open-source HarmonyOS system of a first device. The first device is pre-networked with multiple second devices that have the open-source HarmonyOS system installed. The apparatus includes: The operation log generation module is used to create a target file operation log for the standard file operation command whenever a standard file operation command for the target second device is detected, and to clear the record temporary storage area while writing the target file operation log to the main storage area. The operation execution module is used to execute standard file operation instructions through the distributed file system in the open-source HarmonyOS system, and update the contents of the target file operation record in the main storage area after the standard file operation instructions are executed; The record migration module is used to, whenever an operation rollback instruction is detected, select, based on the rollback type of the operation rollback instruction, to retrieve the most recently stored historical file operation record from the main storage area and transfer it to the record temporary storage area, or retrieve the most recently stored historical file operation record from the record temporary storage area and transfer it to the main storage area. The backtracking operation execution module is used to determine the backtracking file operation instruction based on the backtracking type and the transferred historical file operation records, and execute the backtracking file operation instruction through the distributed file system in the open-source HarmonyOS system.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the cross-device file operation method based on the open-source HarmonyOS system as described in any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a processor to execute and implement the cross-device file operation method based on the open-source HarmonyOS system as described in any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the method as described in any embodiment of the present invention.

[0010] The technical solution of this invention provides a unified, reliable, and low-latency cross-device file operation undo and redo mechanism for multi-device collaborative scenarios. This addresses the lack of cross-device consistency guarantees and real-time backtracking capabilities in existing technologies, significantly improving the fault tolerance and user experience of distributed file management operations. The standard file operation instruction is then executed via the distributed file system in the open-source HarmonyOS system, and the corresponding target file operation record is updated in the main storage area after execution. Whenever an operation rollback instruction is detected, the most recently stored historical file operation record is retrieved from the main storage area and transferred to the record temporary storage area, or the most recently stored historical file operation record is retrieved from the record temporary storage area and transferred to the main storage area, depending on the rollback type. Finally, the rollback file operation instruction is determined based on the rollback type and the transferred historical file operation record, and executed via the distributed file system. This solves the problem of insufficient cross-device consistency guarantees and real-time rollback capabilities in existing technologies, significantly improving the fault tolerance of distributed file management operations and enhancing user experience.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart of a cross-device file operation method based on the open-source HarmonyOS system according to Embodiment 1 of the present invention; Figure 2 This is a flowchart of another cross-device file operation method based on the open-source HarmonyOS system provided in Embodiment 2 of the present invention; Figure 3 This is a basic flowchart illustrating distributed networking and cross-device file operations in a specific scenario applicable to the embodiments of the present invention. Figure 4 This is a schematic diagram of the core process of a file management service recording user operations in a specific scenario applicable to an embodiment of the present invention; Figure 5 This is a schematic diagram of the core data structure for storing and managing operation records in a specific scenario applicable to an embodiment of the present invention; Figure 6 This is a schematic diagram of a cross-device file operation method device based on the open-source HarmonyOS system according to Embodiment 3 of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device that implements a cross-device file operation method based on the open-source HarmonyOS system according to an embodiment of the present invention. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0015] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] Example 1 Figure 1This is a flowchart of a cross-device file operation method based on the open-source HarmonyOS system provided in Embodiment 1 of the present invention. This embodiment can be applied to situations where cross-device file operations need to be undone or redone in a distributed network environment of the open-source HarmonyOS system. The method can be executed by the file management service running on the open-source HarmonyOS system of the first device. The first device is pre-networked with multiple second devices that have the open-source HarmonyOS system installed.

[0017] In this context, the first device can be understood as the initiator, control center, and service provider of the entire cross-device file operation process. Users initiate commands through the file manager application on this device, and its internal "file management service" coordinates all subsequent recording, execution, and backtracking logic. The file management service can be understood as a core system service running on the open-source HarmonyOS system, whose core responsibilities include: receiving and parsing file operation commands from users or applications; and managing the generation, storage, and state migration of operation records. The second device can be understood as the target object of the user's file operation commands, i.e., the remote device where the file actually resides. Distributed networking can be understood as the secure and efficient connection of multiple devices (the first device and several second devices) into a logically unified process and state based on the distributed capabilities of open-source HarmonyOS (especially the distributed soft bus DSoftBus).

[0018] Correspondingly, such as Figure 1 As shown, the method includes: S110. Whenever a standard file operation instruction for the target second device is detected, a target file operation record for the standard file operation instruction is created, and the record temporary storage area is cleared while the target file operation record is written to the main storage area.

[0019] The main storage area can be understood as a storage area that stores all operation records that "users have successfully executed and the system is currently in the result state" in chronological order. Whenever a file operation (such as copying or moving) is successfully completed, its complete record is created and stored here. The record staging area can be understood as a temporary storage area specifically used to temporarily store records that "have just been moved from the main storage area and whose undo operations have been performed".

[0020] In this embodiment, when the file management service receives a file operation request (e.g., copy or move a file) from an application for another networked device, it does not immediately execute the operation. Its primary action is to initiate a recording process: generating a globally unique identifier and creating a "file operation record" object. This object records the caller information, the specific type of the operation (e.g., copy), and the serialized operation parameters (e.g., the paths to the source and target files). Subsequently, this newly created record object, marked as "in progress," is added to the end of the main storage area. Simultaneously, whatever was previously in the record staging area is completely cleared. This ensures that any new operation opens a completely new, linear historical path, preventing old redo records from interfering with the new operation sequence.

[0021] Furthermore, based on the above embodiments, before creating a target file operation record for the standard file operation instruction whenever a standard file operation instruction for the target second device is detected, the following may also be included: Obtain a list of trusted distributed devices from each of the second devices that have successfully formed a distributed network; In response to the selection of a target second device from the list of trusted distributed devices, a connection request is initiated to the distributed file system, wherein the connection request carries the network identifier of the target second device; After receiving the successful connection response from the distributed file system, the public file directory of the target second device is mounted to the mount path corresponding to the network identifier in the local application sandbox of the first device.

[0022] Generally, before the file management service can accept user commands, its underlying framework operates first. Based on the successfully established distributed network relationships between devices, it interacts with the module responsible for device discovery and authentication. This module, according to preset security policies and authentication results, filters out devices trusted by the current account and capable of data collaboration from all connected peripheral devices, generating a clear list for subsequent use. This list ensures that all subsequent file operations are performed only between secure and authorized devices.

[0023] Generally, when a user selects a specific target device from the aforementioned list of trusted devices via the interface, the file management service initiates deep file access collaboration with that device, sending a formal connection request to the open-source HarmonyOS distributed file system. Crucial information in this request is the target device's network identifier, which uniquely identifies the object to be connected to within the network. Upon receiving this request, the distributed file system utilizes its existing distributed soft bus channel to establish a dedicated point-to-point connection with the target device for file services.

[0024] Generally, after the distributed file system successfully establishes a connection with the target device and returns an acknowledgment response, the file management service performs a crucial directory mount operation. This instructs the distributed file system to map specific, publicly accessible directories on the target device to a protected, isolated storage space on the first device's local machine. This local path is typically associated with the target device's network identifier, thus forming a clearly defined access point. Subsequently, file access by users or applications through this local path will be transparently redirected to the actual storage location on the remote target device, thereby achieving a unified view and seamless operation of files across devices.

[0025] S120. Execute standard file operation instructions through the distributed file system in the open-source HarmonyOS system, and update the contents of the target file operation record in the main storage area after the standard file operation instructions are executed.

[0026] In this embodiment, after the record creation is complete, the file management service will actually execute the previously received file operation instructions through the open-source HarmonyOS distributed file system (HMDFS). This distributed file system is responsible for handling cross-device file read and write operations, ensuring that the operations take effect on the relevant devices. Once the operation is completed (whether successful or not), the service will locate the corresponding "in progress" record in the main storage area based on the previously generated unique identifier. Then, the service will fill the record with the actual result code of this operation, the serialized return data (e.g., the path of the newly created file), and the timestamp of the operation's completion, and update its status from "in progress" to "completed".

[0027] S130. Whenever an operation rollback instruction is detected, depending on the rollback type of the operation rollback instruction, either retrieve the most recently stored historical file operation record from the main storage area and transfer it to the record temporary storage area, or retrieve the most recently stored historical file operation record from the record temporary storage area and transfer it to the main storage area.

[0028] In this embodiment, when a user triggers an "Undo" or "Redo" command through the interface, the file management service receives the corresponding "Operation Rewind Instruction." The service first parses the instruction to determine whether its specific "Rewind Type" is "Undo" or "Redo." If it is an Undo instruction, the service will search for and retrieve the last historical file operation record in the "Main Storage Area" with a "Completed" status, as the target record to be processed. Then, the record will be removed from the "Main Storage Area" and moved to the "Record Temporary Storage Area." If it is a Redo instruction, the process is reversed: the service will retrieve the last historical record in the "Record Temporary Storage Area" as the target record and remove it from the "Record Temporary Storage Area."

[0029] S140. Based on the backtracking type and the transferred historical file operation records, determine the backtracking file operation instruction, and execute the backtracking file operation instruction through the distributed file system in the open-source HarmonyOS system.

[0030] In this embodiment, the file rollback operation is directly triggered by the record's state transition. If this transition is initiated by an undo command, the target record that was just moved from the main storage area to the record staging area is parsed, and based on the original operation type and parameters recorded therein, a corresponding reverse operation command is generated and executed through the distributed file system, thereby rolling back the file state to before the original operation was executed. If the transition is initiated by a redo command, the target record that was just removed from the record staging area is parsed, and based on the original operation type and parameters recorded therein, the same original operation request is re-initiated and executed, thereby restoring the file state to after the original operation was executed, thus canceling the undo operation.

[0031] The technical solution of this invention provides a unified, reliable, and low-latency cross-device file operation undo and redo mechanism for multi-device collaborative scenarios. This addresses the lack of cross-device consistency guarantees and real-time backtracking capabilities in existing technologies, significantly improving the fault tolerance and user experience of distributed file management operations. The standard file operation instruction is then executed via the distributed file system in the open-source HarmonyOS system, and the corresponding target file operation record is updated in the main storage area after execution. Whenever an operation rollback instruction is detected, the most recently stored historical file operation record is retrieved from the main storage area and transferred to the record temporary storage area, or the most recently stored historical file operation record is retrieved from the record temporary storage area and transferred to the main storage area, depending on the rollback type. Finally, the rollback file operation instruction is determined based on the rollback type and the transferred historical file operation record, and executed via the distributed file system. This solves the problem of insufficient cross-device consistency guarantees and real-time rollback capabilities in existing technologies, significantly improving the fault tolerance of distributed file management operations and enhancing user experience.

[0032] Example 2 Figure 2 This is a flowchart of another cross-device file operation method based on the open-source HarmonyOS system provided in Embodiment 2 of the present invention. This embodiment is based on the above embodiments and optimized. Specifically, the operation of "whenever a standard file operation instruction for the target second device is detected, a target file operation record for the standard file operation instruction is created, and the record temporary storage area is cleared while the target file operation record is written to the main storage area" is refined.

[0033] Correspondingly, such as Figure 2 As shown, the method includes: S210. In the detected standard file operation instructions, the operation type and operation parameters are parsed out, and a globally unique value is generated as the unique operation identifier of the target file operation record.

[0034] In this embodiment, when the file management service receives a file operation command from the application layer for a connected second device, its primary task is not immediate execution, but rather parsing and recording the command. The file management service extracts the operation type (e.g., copy, move, or delete) and specific operation parameters (typically including the paths to the source and target files, serialized into a specific string format) from the command. Simultaneously, to uniquely track and manage this operation in subsequent processes, a globally unique value is generated as an identification for this operation, i.e., a "unique operation identifier." This identifier is typically generated using a continuously incrementing counter to ensure its uniqueness.

[0035] S220. Based on the unique operation identifier, the parsed operation type and operation parameters, create a target file operation record and mark the execution status of the target file operation record as in progress.

[0036] In this embodiment, based on all the parsed and generated information, the file management service formally creates a structured "target file operation record." This record is a data object containing multiple fields, including a "unique operation identifier," "operation type," and serialized "operation parameters," as well as the caller's identity information and the operation's start timestamp. Crucially, at the initial creation, the record object's "execution status" is explicitly marked as "in progress," indicating that the operation has been recorded, but the actual execution process is not yet complete or the result is unknown. This logically lays the foundation for subsequent completion updates and status tracking. S230. The target file operation record is added to the logical end of the main storage area, and all contents stored in the record temporary storage area are cleared, wherein the main storage area is a circular storage area.

[0037] In this embodiment, the created "in progress" record is immediately sent to the queue used to store historical operations (i.e., the main storage area). This main storage area is structurally a circular storage area (in the form of an Undo circular array), meaning it has a logical tail. New records are always added to this tail to maintain the chronological order of operations. Simultaneously with the addition of this new record, all contents in another queue used to store redoable records (i.e., the record buffer) are unconditionally cleared.

[0038] S240. Execute standard file operation instructions through the distributed file system in the open-source HarmonyOS system, and update the contents of the target file operation record in the main storage area after the standard file operation instructions are executed.

[0039] Optionally, based on the above embodiments, executing standard file operation instructions through the distributed file system in the open-source HarmonyOS system, and updating the content in the target file operation record in the main storage area after the standard file operation instructions have been executed, may include: Call the standard interface of the distributed file system to complete the file operations defined by the standard file operation instructions; Obtain the execution result code and return data returned by the standard interface after execution, and synchronously obtain the operation end time; The execution result code, return data, and operation completion time are filled into the target file operation record in the main storage area, and the execution status of the target file operation record is remarked as "completed".

[0040] Fill in the located object and update the object's status flag to complete.

[0041] Generally, when a file management service needs to perform a file operation, it sends a call request to the underlying distributed file system. This request is made through a predefined standard interface, and its content is entirely based on the specific operations defined by the previously parsed and recorded standard file operation instructions, such as copying or moving files. The distributed file system is responsible for completing the actual file reading, writing and status changes across devices.

[0042] Generally, after a distributed file system completes a requested file operation through the standard interface, regardless of whether the operation succeeds or fails, it will return a clear execution result code to the file management service via the same interface to indicate the final status. This code may also include serialized return data, such as the path to the newly created file. Upon receiving this feedback, the service will record the precise time the operation was completed as the operation's end time.

[0043] Generally, the file management service then locates the corresponding record in the main storage area that is still in "in progress" based on the unique operation identifier of the target file operation record. It then completely fills in the specified fields of that record with the three key pieces of information: the obtained execution result code, the returned data, and the operation completion time. After the information is filled in, the execution status of the target file operation record is changed from "in progress" to "completed," thus marking that the entire lifecycle of this file operation from initiation to completion has been fully recorded, forming a definitive historical record that can be traced and back later.

[0044] S250. Whenever an operation rollback instruction is detected, depending on the rollback type of the operation rollback instruction, either retrieve the most recently stored historical file operation record from the main storage area and transfer it to the record temporary storage area, or retrieve the most recently stored historical file operation record from the record temporary storage area and transfer it to the main storage area.

[0045] Optionally, based on the above embodiments, depending on the rollback type of the operation rollback instruction, one can select to retrieve the most recently stored historical file operation record from the main storage area and transfer it to the record temporary storage area, or retrieve the most recently stored historical file operation record from the record temporary storage area and transfer it to the main storage area, including: If the rollback type of the operation rollback instruction is an undo instruction, then the most recently stored historical file operation record is retrieved from the main storage area and transferred to the record temporary storage area. If the rollback type of the operation rollback instruction is a redo instruction, then the most recently stored historical file operation record is retrieved from the record staging area and transferred to the main storage area.

[0046] Generally, when the file management service receives an operation rollback command from a user, it first parses the command to determine whether it is an undo or redo command. This determination forms the basis for all subsequent branch operations.

[0047] Generally, if the parsed rollback type is an undo command, the file management service will search in the main storage area. Its search target is the last historical file operation record in that storage area, whose execution status is explicitly marked as completed. After successfully retrieving this record, the service removes it from the main storage area and places it in the record staging area. This operation changes the logical ownership of the record, transforming it from a completed record that can be traced back and rolled back to a staging state that may be re-executed.

[0048] Generally, if the parsed rollback type is a redo instruction, the file management service operates in the opposite direction. It will turn to the record staging area and retrieve the last historical file operation record arranged in storage order. Subsequently, this record will be removed from the record staging area. This process indicates that the record, which was staging due to a previous undo operation, is now officially responding to its mission as a "redoable" option, and the original operation will be re-executed based on its content.

[0049] Furthermore, based on the above embodiments, depending on the rollback type of the operation rollback instruction, selecting to retrieve the most recently stored historical file operation record from the main storage area and transfer it to the record temporary storage area, or retrieving the most recently stored historical file operation record from the record temporary storage area and transferring it to the main storage area, may further include: If the historical file operation record is not successfully retrieved from the main storage area or the record staging area, a corresponding failure backtracking prompt is generated, and the failure backtracking prompt is used as the response result to the operation backtracking instruction.

[0050] Generally, when a file management service responds to an operation rollback command, whether it's an undo or redo, its first step is to attempt to retrieve a valid historical file operation record from the specified storage area. This attempt may fail because the corresponding storage area is empty or contains no matching record. If the search for an undo command fails to find any historical file operation record with a completed execution status in the main storage area, or if the search for a redo command fails to find any record in the record staging area, the retrieval operation is considered to have failed. This failure status means that subsequent file status rollback or recovery cannot be performed according to the user's instructions. Once the record retrieval fails, a clear and structured failure rollback message is immediately generated based on the specific failure scenario (e.g., whether there is no undoable record or no redoable record). This message includes the reason code and description of the operation failure, aiming to accurately inform the caller why the requested undo or redo action cannot be executed. After successfully generating the failure rollback message, the file management service terminates the subsequent processing flow for this operation rollback command and no longer attempts to generate or execute any rollback file operation commands. Instead, the newly generated failure backtracking message will be taken as the final result of this processing operation and returned directly to the caller who initially initiated the backtracking command, thus completing the response to the entire command.

[0051] S260. Based on the backtracking type and the transferred historical file operation records, determine the backtracking file operation instruction, and execute the backtracking file operation instruction through the distributed file system in the open-source HarmonyOS system.

[0052] Optionally, based on the above embodiments, according to the backtracking type and the transferred historical file operation records, a backtracking file operation instruction is determined, including: If the rollback type of the operation rollback instruction is an undo instruction, then a matching reverse operation instruction is generated based on the operation type and operation parameters recorded in the historical file operation records transferred from the main storage area to the record temporary storage area, and used as the rollback file operation instruction. If the rollback type of the operation rollback instruction is a redo instruction, then a matching standard file operation instruction is generated based on the operation type and operation parameters recorded in the historical file operation records transferred from the record temporary area to the main storage area, and used as the rollback file operation instruction.

[0053] Generally, when the rollback type of an operation rollback instruction is determined to be an undo instruction, the file management service immediately processes the specific historical file operation record that was just transferred from the main storage area to the record staging area. The service reads the original operation type and serialized operation parameters detailed in the record. Based on this information, the service can accurately deduce and generate an operation instruction that is logically completely opposite to it. This newly generated instruction is the reverse operation instruction that needs to be executed this time, and it is determined to be the final rollback file operation instruction, with the purpose of reverting the file state to the state before the original operation was executed.

[0054] Generally, when the rollback type of an operation rollback instruction is determined to be a redo instruction, the file management service processes the specific historical file operation record that was just moved from the record staging area. The service parses the original operation type and serialized operation parameters stored in the record, and based on this information, reconstructs an instruction that is exactly the same as the original undone operation. This newly generated instruction is the standard file operation instruction to be executed this time, and it is determined as the final rollback file operation instruction, with the purpose of restoring the file state to the state after the original operation was successfully executed.

[0055] The technical solution of this invention involves, when a standard file operation instruction for a target second device is detected, parsing the operation type and operation parameters, and generating a globally unique value as a unique operation identifier for the target file operation record; based on this unique operation identifier, the parsed operation type and operation parameters, creating a target file operation record and marking its execution status as in progress; subsequently, adding the record to the logical end of the main storage area and clearing all content stored in the record temporary storage area; then executing the standard file operation instruction through the distributed file system of the open-source HarmonyOS system, and updating the content of the corresponding record in the main storage area after the instruction execution is completed; when an operation rollback instruction is detected... When the time comes, depending on the type of backtracking, the system selects to retrieve the most recently stored historical file operation record from the main storage area and transfer it to the record staging area, or retrieve the most recently stored historical file operation record from the record staging area and transfer it to the main storage area. Finally, based on the backtracking type and the transferred historical file operation record, the backtracking file operation instruction is determined and executed through the distributed file system. This provides a native, consistent, and efficient operation history backtracking mechanism for multi-device collaboration scenarios in open-source HarmonyOS, solving the problem that existing solutions cannot achieve reliable and low-latency file operation undoing and redoing in cross-device environments. It has achieved significant benefits in improving the fault tolerance of distributed file management, ensuring data operation security, and enhancing user experience.

[0056] To facilitate understanding, the specific application scenarios applicable to each embodiment of the present invention are described below. In this specific embodiment, addressing the common need for users of the open-source HarmonyOS distributed operating system to frequently perform cross-device file operations during multi-device collaborative work, and their high requirements for operational fault tolerance, the present invention designs a complete cross-device file operation history backtracking scheme based on distributed file system metadata synchronization and dual-zone operation record management. This aims to provide users with undo and redo functions that are consistent with single-machine operation experience, with low latency and unified status.

[0057] Specifically, Figure 3 This is a schematic diagram illustrating the basic process of distributed networking and cross-device file operations in an embodiment of the present invention. Figure 3 As shown, the process begins by retrieving a list of all authenticated trusted distributed devices (corresponding to the function `getDistributedDeviceList`). After selecting a target device from this list, the user calls the `connectDfs` function to initiate a connection request to the distributed file system to establish a point-to-point communication link with the target device. Once the connection is successful, the user can perform file or folder operations on the public directories mounted on the target device, including but not limited to copying, moving, and renaming. All operations are performed through the distributed file system to ensure cross-device consistency. After the operation is complete, the user can call the `disconnectDfs` function to disconnect, ending the process. This process provides the necessary network and mounting environment for subsequent operation logging and backtracking.

[0058] Figure 4 This is a schematic diagram illustrating the core process of the file management service recording user operations in an embodiment of the present invention. For example... Figure 4As shown, the process begins with a user initiating a file operation (such as copying or moving). The key is that the actual business logic (i.e., the "original operation logic") is wrapped in two steps: "start recording operation (startRecord)" and "end recording operation (endRecord)". When the service starts, the permission management interface is dynamically called to grant the file management service the ohos.permission.DISTRIBUTED_DATASYNC permission, ensuring its cross-device data synchronization capability. The startRecord step is called before the operation is executed, responsible for generating an operation record containing a unique identifier, operation type, and parameters, marking its status as "in progress," and clearing the redo record staging area. Subsequently, the actual cross-device file operation is executed through the distributed file system. After the operation is completed, the endRecord step is called, finding the corresponding record based on the unique identifier, updating the operation result and timestamp, and marking its status as "completed," thus forming a complete and traceable operation history. This design achieves non-intrusive auditing and capture of every file operation, laying the data foundation for undo and redo functions.

[0059] Figure 5 This is a schematic diagram of the class structure of a circular array, the core data structure used for storing and managing operation records in this embodiment of the invention. Figure 5 As shown, this class defines key properties for managing the operation record queue: `capacity` represents the fixed capacity of the circular array, used to limit the maximum number of historical records and prevent infinite memory growth; `size` represents the number of records currently stored in the array; `recordArray` is a storage area based on a regular array, used to actually store Record objects; `frontIndex` points to the storage position of the earliest added record in the logical queue (head), and `rearIndex` points to the free position where the next new record can be stored (tail). These two are updated together to achieve cyclic access and management of records in the circular array. Its constructor requires a positive integer to initialize the capacity. In this scheme, two instances of this circular array will be created, serving as the "main storage area" (i.e., the Undo circular array) and the "record temporary storage area" (i.e., the Redo circular array), respectively. The main storage area stores completed operation records in chronological order; records transferred from the main storage area to the record temporary storage area correspond to undo operations. The record temporary storage area temporarily stores undoed records; removing a record from the record temporary storage area immediately triggers a new file operation. This data structure is the core of achieving linear management of operation history, fixed-capacity storage, and efficient record migration.

[0060] Example 3 Figure 6This invention provides a cross-device file operation device based on the open-source HarmonyOS system, as described in Embodiment 3 of the present invention. The device is executed by a file management service running on the open-source HarmonyOS system of a first device. The first device is pre-networked with multiple second devices that have the open-source HarmonyOS system installed. The device includes: The operation record generation module 610 is used to create a target file operation record for the standard file operation command whenever a standard file operation command for the target second device is detected, and to clear the record temporary storage area while writing the target file operation record to the main storage area. The operation execution module 620 is used to execute standard file operation instructions through the distributed file system in the open-source HarmonyOS system, and update the contents of the target file operation record in the main storage area after the standard file operation instructions are executed. The record migration module 630 is used to, whenever an operation rollback instruction is detected, select, based on the rollback type of the operation rollback instruction, to retrieve the most recently stored historical file operation record from the main storage area and transfer it to the record temporary storage area, or to retrieve the most recently stored historical file operation record from the record temporary storage area and transfer it to the main storage area. The backtracking operation execution module 640 is used to determine the backtracking file operation instruction based on the backtracking type and the transferred historical file operation records, and execute the backtracking file operation instruction through the distributed file system in the open-source HarmonyOS system.

[0061] The technical solution of this invention provides a unified, reliable, and low-latency cross-device file operation undo and redo mechanism for multi-device collaborative scenarios. This addresses the lack of cross-device consistency guarantees and real-time backtracking capabilities in existing technologies, significantly improving the fault tolerance and user experience of distributed file management operations. The standard file operation instruction is then executed via the distributed file system in the open-source HarmonyOS system, and the corresponding target file operation record is updated in the main storage area after execution. Whenever an operation rollback instruction is detected, the most recently stored historical file operation record is retrieved from the main storage area and transferred to the record temporary storage area, or the most recently stored historical file operation record is retrieved from the record temporary storage area and transferred to the main storage area, depending on the rollback type. Finally, the rollback file operation instruction is determined based on the rollback type and the transferred historical file operation record, and executed via the distributed file system. This solves the problem of insufficient cross-device consistency guarantees and real-time rollback capabilities in existing technologies, significantly improving the fault tolerance of distributed file management operations and enhancing user experience.

[0062] Based on the above embodiments, a cross-device file operation device based on the open-source HarmonyOS system may further include: The trusted device module is used to obtain a list of trusted distributed devices from each of the second devices that have successfully formed a distributed network, before creating a target file operation record for the standard file operation instruction whenever a standard file operation instruction for the target second device is detected. In response to the selection of a target second device from the list of trusted distributed devices, a connection request is initiated to the distributed file system, wherein the connection request carries the network identifier of the target second device; After receiving the successful connection response from the distributed file system, the public file directory of the target second device is mounted to the mount path corresponding to the network identifier in the local application sandbox of the first device.

[0063] Optionally, based on the above embodiments, the operation record generation module 610 is specifically used for: In the detected standard file operation instructions, the operation type and operation parameters are parsed out, and a globally unique value is generated as the unique operation identifier of the target file operation record. Based on the unique operation identifier, the parsed operation type and operation parameters, a target file operation record is created, and the execution status of the target file operation record is marked as in progress. The target file operation record is added to the logical end of the main storage area, and all content stored in the record temporary storage area is cleared, wherein the main storage area is a circular storage area.

[0064] Optionally, based on the above embodiments, the operation execution module 620 is specifically used for: Call the standard interface of the distributed file system to complete the file operations defined by the standard file operation instructions; Obtain the execution result code and return data returned by the standard interface after execution, and synchronously obtain the operation end time; The execution result code, return data, and operation end time are filled into the target file operation record in the main storage area, and the execution status of the target file operation record is remarked as completed.

[0065] Fill in the located object and update the object's status flag to complete.

[0066] Optionally, based on the above embodiments, the migration recording module 630 is specifically used for: If the rollback type of the operation rollback instruction is an undo instruction, then the most recently stored historical file operation record is retrieved from the main storage area and transferred to the record temporary storage area. If the rollback type of the operation rollback instruction is a redo instruction, then the most recently stored historical file operation record is retrieved from the record staging area and transferred to the main storage area.

[0067] Optionally, based on the above embodiments, the backtracking operation execution module 640 is specifically used for: If the rollback type of the operation rollback instruction is an undo instruction, then a matching reverse operation instruction is generated based on the operation type and operation parameters recorded in the historical file operation records transferred from the main storage area to the record temporary storage area, and used as the rollback file operation instruction. If the rollback type of the operation rollback instruction is a redo instruction, then a matching standard file operation instruction is generated based on the operation type and operation parameters recorded in the historical file operation records transferred from the record temporary area to the main storage area, and used as the rollback file operation instruction.

[0068] Based on the above embodiments, the migration recording module 630 may further include: The failure backtracking submodule is used to generate a corresponding failure backtracking prompt if the historical file operation record is not successfully retrieved in the main storage area or the record temporary storage area, and to use the failure backtracking prompt as the response result to the operation backtracking instruction.

[0069] The cross-device file operation device based on the open-source HarmonyOS provided in the embodiments of the present invention can execute the cross-device file operation method based on the open-source HarmonyOS provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0070] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0071] Example 4 Figure 7 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0072] like Figure 7As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0073] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0074] Processor 11 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing unit (CPU), graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as performing a cross-device file operation method based on the open-source HarmonyOS system as described in any embodiment of the present invention, namely: Whenever a standard file operation command for the target second device is detected, a target file operation record for the standard file operation command is created, and the record temporary storage area is cleared while the target file operation record is written to the main storage area. The system executes standard file operation instructions through the distributed file system in the open-source HarmonyOS system, and updates the contents of the target file operation record in the main storage area after the standard file operation instructions are executed. Whenever an operation rollback instruction is detected, depending on the rollback type of the operation rollback instruction, either retrieve the most recently stored historical file operation record from the main storage area and transfer it to the record temporary storage area, or retrieve the most recently stored historical file operation record from the record temporary storage area and transfer it to the main storage area. Based on the backtracking type and the transferred historical file operation records, the backtracking file operation instructions are determined and executed through the distributed file system in the open-source HarmonyOS system.

[0075] In some embodiments, a cross-device file operation method based on the open-source HarmonyOS system, as described in any one of the embodiments of the present invention, can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the cross-device file operation method based on the open-source HarmonyOS system described above can be performed. Alternatively, in other embodiments, processor 11 can be configured by any other suitable means (e.g., by means of firmware) to perform the cross-device file operation method based on the open-source HarmonyOS system described in any one of the embodiments of the present invention.

[0076] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0077] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0078] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0079] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0080] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0081] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0082] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0083] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A cross-device file operation method based on the open-source HarmonyOS system, characterized in that, The method is executed by a file management service running on the open-source HarmonyOS system on a first device, which is pre-networked with multiple second devices that have the open-source HarmonyOS system installed. The method includes: Whenever a standard file operation command for the target second device is detected, a target file operation record for the standard file operation command is created, and the record temporary storage area is cleared while the target file operation record is written to the main storage area. The system executes standard file operation instructions through the distributed file system in the open-source HarmonyOS system, and updates the contents of the target file operation record in the main storage area after the standard file operation instructions are executed. Whenever an operation rollback instruction is detected, depending on the rollback type of the operation rollback instruction, either retrieve the most recently stored historical file operation record from the main storage area and transfer it to the record temporary storage area, or retrieve the most recently stored historical file operation record from the record temporary storage area and transfer it to the main storage area. Based on the backtracking type and the transferred historical file operation records, the backtracking file operation instructions are determined and executed through the distributed file system in the open-source HarmonyOS system.

2. The method according to claim 1, characterized in that, Before creating a target file operation record for each standard file operation instruction detected on the target second device, the following is also included: Obtain a list of trusted distributed devices from each of the second devices that have successfully formed a distributed network; In response to the selection of a target second device from the list of trusted distributed devices, a connection request is initiated to the distributed file system, wherein the connection request carries the network identifier of the target second device; After receiving the successful connection response from the distributed file system, the public file directory of the target second device is mounted to the mount path corresponding to the network identifier in the local application sandbox of the first device.

3. The method according to claim 1, characterized in that, Whenever a standard file operation command for the target second device is detected, a target file operation record for the standard file operation command is created, and the record buffer is cleared while the target file operation record is written to the main storage area, including: In the detected standard file operation instructions, the operation type and operation parameters are parsed out, and a globally unique value is generated as the unique operation identifier of the target file operation record. Based on the unique operation identifier, the parsed operation type and operation parameters, a target file operation record is created, and the execution status of the target file operation record is marked as in progress. The target file operation record is added to the logical end of the main storage area, and all content stored in the record temporary storage area is cleared, wherein the main storage area is a circular storage area.

4. The method according to claim 3, characterized in that, The system executes standard file operation instructions through the distributed file system in the open-source HarmonyOS system, and updates the contents of the target file operation record in the main storage area after the standard file operation instructions have been executed, including: Call the standard interface of the distributed file system to complete the file operations defined by the standard file operation instructions; Obtain the execution result code and return data returned by the standard interface after execution, and synchronously obtain the operation end time; The execution result code, return data, and operation end time are filled into the target file operation record in the main storage area, and the execution status of the target file operation record is remarked as completed. Fill in the located object and update the object's status flag to complete.

5. The method according to any one of claims 1-4, characterized in that, Depending on the rollback type of the operation rollback instruction, the system may choose to retrieve the most recently stored historical file operation record from the main storage area and transfer it to the record staging area, or retrieve the most recently stored historical file operation record from the record staging area and transfer it to the main storage area, including: If the rollback type of the operation rollback instruction is an undo instruction, then the most recently stored historical file operation record is retrieved from the main storage area and transferred to the record temporary storage area. If the rollback type of the operation rollback instruction is a redo instruction, then the most recently stored historical file operation record is retrieved from the record staging area and transferred to the main storage area.

6. The method according to claim 5, characterized in that, Based on the backtracking type and the transferred historical file operation records, determine the backtracking file operation instructions, including: If the rollback type of the operation rollback instruction is an undo instruction, then a matching reverse operation instruction is generated based on the operation type and operation parameters recorded in the historical file operation records transferred from the main storage area to the record temporary storage area, and used as the rollback file operation instruction. If the rollback type of the operation rollback instruction is a redo instruction, then a matching standard file operation instruction is generated based on the operation type and operation parameters recorded in the historical file operation records transferred from the record temporary area to the main storage area, and used as the rollback file operation instruction.

7. The method according to claim 5, characterized in that, Based on the rollback type of the operation rollback instruction, the system may choose to retrieve the most recently stored historical file operation record from the main storage area and transfer it to the record temporary storage area, or retrieve the most recently stored historical file operation record from the record temporary storage area and transfer it to the main storage area, further including: If the historical file operation record is not successfully retrieved from the main storage area or the record staging area, a corresponding failure backtracking prompt is generated, and the failure backtracking prompt is used as the response result to the operation backtracking instruction.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the cross-device file operation method based on the open-source HarmonyOS system as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the cross-device file operation method based on the open-source HarmonyOS system as described in any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the cross-device file operation method based on the open-source HarmonyOS system according to any one of claims 1-7.

Images