Method and device for validating changes in a hierarchical file system

Abstract

The disclosure relates to a method and device for validating changes in a hierarchical file system. The method and device involve initializing a global counter and associating a validation value with each data block in the hierarchical file system. During an update, the validation value of the data block is temporarily increased to indicate that it is being modified. Once the update is completed, the global counter is incremented to validate the updated data blocks, ensuring their synchronization and consistency within the system.

Description

[0001] METHOD AND DEVICE FOR VALIDATING CHANGES IN A HIERARCHICAL FILE SYSTEM

[0002] The disclosure relates to a method and device for validating changes in a hierarchical file system. Further a computer program is provided that includes instructions which, when executed by a computer, cause the computer to perform the method at least in part.

[0003] Current state-of-the-art techniques involve various methods for ensuring the validity and consistency of changes in file systems. A commonly employed approach is transactionbased validation, where modifications are only considered valid if all sub-operations are successfully completed. This approach typically requires significant memory capacity and computational power to manage and verify atomic transactions. As a result, it becomes challenging to implement on embedded devices with constrained resources. Furthermore, many existing solutions are limited to specific levels within a hierarchical file system, making it complex and error-prone to handle changes spanning multiple levels. The scalability of these solutions is also restricted, as the administrative overhead increases significantly with the number of data blocks being modified, leading to substantial performance degradation, particularly in systems with limited resources.

[0004] One notable approach in the state of the art relies on a patented mechanism that enables atomic transaction validation. However, this solution requires substantial licensing fees and has therefore only been adopted by a small number of companies.

[0005] Despite the advances in this domain, significant challenges persist. The complexity of managing and validating changes often necessitates additional mechanisms that increase memory requirements and energy consumption. Existing methods frequently lack robust fault tolerance, leaving file systems vulnerable to inconsistencies during sudden system interruptions, such as power failures. These inconsistencies often require extensive recovery procedures to resolve. Furthermore, many of the current techniques are designed for specific platforms or applications, limiting their applicability in broader contexts.

[0006] In light of these challenges, there is a clear need for a simpler, more robust, and universally applicable validation mechanism that addresses these limitations. With regard to the outlined prior art, the objective of the present disclosure is to provide a method and / or a device, each of which is suitable for enriching the state of the art.

[0007] This objective is achieved by the features of the independent claims. The further independent claims and the dependent claims respectively contain optional further developments of the disclosure.

[0008] The objective is achieved, according to a first aspect, by a method for validating changes in a hierarchical file system.

[0009] The method is aimed at ensuring the consistency and reliability of updates made to a hierarchical file system. The process of validating updates ensures that data blocks remain consistent, even during interruptions, and eliminates the need for complex transaction mechanisms. The term validating can refer to confirming the integrity and correctness of modifications made to the data blocks within a file system. Validation involves ensuring that updated blocks meet specific criteria for consistency and correctness before they are marked as valid. The term changes in a hierarchical file system can refer to any modifications, additions, deletions, or updates made to data blocks within a file system that is structured hierarchically, such as one organized into directories and subdirectories.

[0010] The step of providing a global validation counter, VC, and a corresponding validation value, VV, for each data block in the hierarchical file system establishes the foundational elements required for the method, namely the global validation counter and the validation value for each data block. The global validation counter, VC, can refer to a single integer value that acts as a system-wide reference for validating updates. In an embodiment, the system may contain multiple VCs, each of them is controlling a sub-part of the hierarchical file system. E.g., different application owners. The counter tracks the current state of validation across all data blocks within the file system. The VC facilitates a centralized mechanism for determining which data blocks are considered valid. The validation value, VV, can refer to an integer value assigned to each data block, representing the state of the block with respect to the current VC. A higher VV indicates a more recent update that has not yet been validated. The term data block can refer to the smallest unit of data within the hierarchical file system, such as a fixed-size segment of storage that contains user or system data. This step enables the system to implement a robust and scalable validation mechanism. By associating each data block with a VV and comparing it to the VC, the method or device can determine the validity of updates with minimal computational overhead.

[0011] The step of setting the VV of a data block to a value greater than the current value of the VC while the data block is being updated involves temporarily marking a data block as invalid during the update process. By setting the VV of a data block to a value greater than the current value of the VC, the system ensures that the update is not considered valid until explicitly validated. The term value greater can refer to an integer value that exceeds the current VC, signifying that the update is pending validation. A current value of the VC can refer to the existing integer value of the VC at the time the update is initiated. Further being updated can refer to the process during which a data block is modified, added, or deleted. During this process, the data block's integrity is not yet confirmed, necessitating a temporary invalid state. This step can ensure that updates are managed in a controlled and predictable manner. By isolating unvalidated updates, the system prevents inconsistencies and ensures that only validated data is accessible.

[0012] The step of validating all updated data blocks by incrementing the value of the VC, thereby marking all VVs that are less than or equal to the VC as valid finalizes the updates by incrementing the VC, which automatically validates all associated data blocks with VVs less than or equal to the updated VC. Incrementing the value of the VC can refer to increasing the integer value of the VC by one or more units to signify the completion of a validation cycle. This feature provides a highly efficient method for validating multiple data blocks simultaneously. By relying on a simple incrementation of the VC, the method or device eliminates the need for complex validation processes and reduces computational overhead. It also enhances fault tolerance, as partially updated data blocks can remain invalid until explicitly validated. By ensuring that only data blocks with VVs less than or equal to the VC are valid, the method provides robust protection against data corruption during interruptions, such as power failures.

[0013] The method offers a number of benefits. Among other things, the method provides technical benefits in the context of validating changes within hierarchical file systems, particularly for embedded systems with resource constraints. By introducing a global validation counter and a validation value for each data block, the method eliminates the need for complex transaction management or additional overhead structures, thereby reducing memory and computational requirements. The simplicity of the mechanism ensures scalability, as the number of pending updates has no impact on performance; validation remains efficient regardless of the number of modified data blocks. Furthermore, the method inherently enhances fault tolerance by allowing already committed updates to survive interruptions, such as power failures, without requiring additional recovery processes. It enables atomic transactions through a single increment of the VC, ensuring consistent data states across the file system. Unlike existing solutions, the method is not restricted to specific levels of a hierarchical file system and supports modifications across multiple layers with equal efficiency. Additionally, the approach facilitates the creation of a revision history, enabling backward and forward navigation through data states by manipulating the VC, thereby enhancing usability and data management flexibility. This robust and efficient solution addresses longstanding limitations in the field and provides a versatile tool for maintaining data consistency across diverse applications.

[0014] For application cases or application situations that may arise during the executed methods and are not explicitly described herein, it may be provided that, according to the method, an error message and / or a prompt for user feedback is output, and / or a default setting and / or a predetermined initial state is set.

[0015] The methods may involve a computer-implemented method, meaning that one, several, or all steps of the methods can be at least partially performed by a computer or a data processing device, optionally a computing device, in particular the device disclosed herein. Where appropriate, it may be provided to execute the steps in a sequence different from that described.

[0016] The following will explain possible refinements of the above-described aspects of the disclosure in detail. Each of the refinements mentioned below can further develop and specify the above-mentioned method either separately or in combination.

[0017] It may be provided that the hierarchical file system comprises multiple hierarchical levels and that the validation is performed independently of the hierarchical level. The hierarchical levels can represent a structure organized into directories and subdirectories, where data blocks reside at different levels. The validation mechanism may rely on the validation counter VC and validation value VV without being influenced by the location of a data block within the hierarchy. By decoupling the validation process from the hierarchical structure, this feature ensures consistent validation across all levels, allowing updates to occur seamlessly across the file system without requiring level-specific adjustments or additional computations.

[0018] It may be provided that, in the event of an interruption during the update of a data block, all data blocks with a validation value greater than the current validation counter are marked as invalid to ensure the consistency of the hierarchical file system. An interruption, such as a power failure or system crash, can leave certain updates incomplete. This feature may utilize a comparison mechanism between VV and VC to identify such data blocks and flag them as invalid, ensuring that only data blocks with completed and validated updates remain accessible. This mechanism prevents inconsistencies and potential corruption in the file system, reducing the need for extensive recovery procedures.

[0019] According to an embodiment, a plurality of global validation counters is implemented and that the highest VC value is considered valid. Each global validation counter can represent an independent instance of the validation process, such as for separate partitions or applications within the file system. The highest VC among all counters is identified and used to determine the validity of data blocks. This approach enables redundancy, allowing to recover or validate data blocks based on the highest available VC, even if other counters are compromised or inactive, thereby enhancing the reliability and robustness of the validation mechanism.

[0020] It may be provided that the method further includes a cleanup step, wherein all invalid or outdated validation values are set to a predefined invalid value, and all valid VVs along with the VC are reset to an initial value.

[0021] For the purposes of the present disclosure, the cleanup step is a systematic procedure within the validation mechanism of a hierarchical file system, designed to restore and maintain the integrity of the validation process over prolonged operation or when specific conditions arise, such as the validation counter (VC) reaching its maximum value. The cleanup step is essential for ensuring the system remains consistent, reliable, and ready for further operations without performance degradation.

[0022] The cleanup step typically involves two main actions. First, all validation values associated with data blocks that are outdated, invalid, or no longer required are set to a predefined invalid value. This invalid value, such as 0x00 or OxFF, acts as a universal marker within the system, signifying that these data blocks are no longer part of the active or valid state of the file system. This process effectively removes obsolete data blocks, clearing them for potential reuse while maintaining clarity in the validation mechanism.

[0023] Second, all valid VVs and the VC are reset to their initial values to restore the system to a clean and consistent state. For example, valid VVs may be reset to a standard starting value, such as VV = 1 , while the VC is reset to an initial count, such as VC = 1. This resetting action ensures that all future operations begin from a uniform baseline, preventing issues related to counter overflow or ambiguity in the validation process.

[0024] The cleanup step may be triggered automatically by the system when the VC approaches its maximum representable value or manually during scheduled maintenance operations. This procedure guarantees the long-term efficiency and reliability of the file system, eliminating outdated or unused data blocks and preserving the consistency of the validation mechanism. It is a vital feature for hierarchical file systems, particularly in embedded systems with constrained resources, where consistent and predictable operation is critical.

[0025] This process ensures that the file system maintains its integrity over prolonged operation by removing outdated data blocks and preventing overflow or inconsistencies in the validation mechanism.

[0026] According to an embodiment, a data block is reactivated after deletion by resetting its validation value (VV) to a valid value. Reactivation may involve assigning the VV of a previously invalidated or deleted data block a value less than or equal to the current VC, restoring its validity. This enables efficient reuse of storage resources by allowing previously deleted data blocks to be reintegrated into the file system without requiring a complete reinitialization or rewriting process.

[0027] It may be provided that, during an update of a data block, the old validation value (VV) is retained until the write operation is fully completed to prevent errors caused by inconsistent data. It ensures that partially written data blocks do not affect the system's consistency. The update process may involve writing the new data to a temporary location (e.g., shadow copy) while the old VV remains unchanged. Only upon successful completion of the write operation is the VV updated, thereby ensuring that data blocks remain accessible in their previous valid state until the update is finalized. It may be provided that the validation is performed atomically by incrementing the value of the validation counter, enabling multiple independent changes to be validated simultaneously. Atomic validation may involve a single increment operation on the VC, which marks all data blocks with VVs less than or equal to the new VC as valid. This feature allows for batch validation of multiple updates without requiring individual validations for each data block, significantly reducing computational overhead and improving system performance.

[0028] According to a further embodiment, the validation counter is a multi-byte value to support a high number of write operations. For example, a 32-bit or 64-bit VC can accommodate billions of increments, making the method suitable for systems with extensive write requirements. This ensures that the validation mechanism operates efficiently over the file system's lifespan without frequent resets or cleanup operations.

[0029] It may be provided that the validation value of a data block is written to a shadow copy before the new VV is integrated into the file system to prevent data loss during an interruption. The shadow copy serves as a temporary storage area for updated VVs, ensuring that the original VV remains unchanged until the update is successfully completed. In the event of an interruption, the system can revert to the original VV, preserving data integrity and preventing incomplete updates from corrupting the file system.

[0030] It may be provided that a plurality of shadow copies is created for each data block, enabling a revision history by using the validation counter to control which shadow copy is considered valid. Each shadow copy may represent a different version of the data block, with the VC indicating the most recent valid version. This feature facilitates the creation of a revision history, allowing the system to maintain and access multiple versions of a data block for purposes such as recovery or auditing.

[0031] It may be provided that the validation counter is configured to select a previous shadow copy as valid, thereby enabling a step back in the revision history. This feature may involve decrementing the VC to a value corresponding to an earlier version of the data block. By enabling backward navigation in the revision history, the system can recover prior data states or undo recent changes, enhancing its flexibility and usability. Up to now, the disclosure has been described with respect to the claimed method. Features, advantages or alternative embodiments herein can be assigned to the other claimed objects (e.g., device, computer program product) and vice versa. In other words, the subject matter which is claimed or described with respect to the claimed method can be improved with features described or claimed in the context of the device and vice versa. In this case, the structural units of the device are embodied by functional features of the method and vice versa, respectively. Generally, in computer science a software implementation and a corresponding hardware implementation are equivalent. Thus, for example, a method step for “storing” data may be performed with a storage unit and respective instructions to write data into the storage. For the sake of avoiding redundancy, although the device may also be used in the alternative embodiments described with reference to the method, these embodiments are not explicitly described again for the device.

[0032] Furthermore, the objective is achieved according to another aspect of the disclosure by a device. The disclosure relates to the device for validating changes in a hierarchical file system. The device comprises a processor unit that is specifically configured to execute the steps necessary to implement the validation mechanism. The device operates within a hierarchical file system, which may include multiple levels such as directories and subdirectories, to ensure that updates are validated consistently and reliably. The following describes the functionality of the device in detail, along with its technical effects and the underlying principles.

[0033] The processor unit of the device is configured to provide a global validation counter, VC, and a corresponding validation value, VV, for each data block in the hierarchical file system. It involves assigning a global validation counter that acts as a centralized reference for validating updates across the entire file system. Each data block in the file system is associated with its own validation value, which indicates the state of the block with respect to the current VC. This configuration ensures that updates can be tracked and validated consistently, regardless of their position within the hierarchical structure. By maintaining a global counter and corresponding values for individual data blocks, the system facilitates centralized and efficient management of data validity. It enables a streamlined validation processes while reducing the complexity of managing hierarchical file systems, particularly in environments with limited computational resources. The processor unit is further configured to set the VV of a data block to a value greater than the current value of the VC while the data block is being updated. During an update operation, the validation value of the data block is temporarily assigned a value higher than the current VC. This marks the data block as invalid during the update process, ensuring that it cannot be accessed or used until the update is complete. This step is critical for maintaining the integrity of the file system by preventing access to partially updated or inconsistent data. The technical effect is to isolate incomplete updates, safeguarding the file system from potential corruption or inconsistencies that may arise due to interruptions or errors during the update process.

[0034] Upon completing the updates, the processor unit is configured to validate all updated data blocks by incrementing the value of the VC, thereby marking all VVs that are less than or equal to the VC as valid. This step involves incrementing the global validation counter, which effectively validates all data blocks with validation values less than or equal to the new value of the VC. This approach provides a simple yet robust mechanism for validating multiple data blocks simultaneously, ensuring that only finalized and consistent updates are made accessible. The technical effect is a streamlined validation process that minimizes computational overhead and ensures the consistency of the hierarchical file system. By incrementing a single counter, the system achieves atomic validation of multiple updates, thereby enhancing its fault tolerance and operational efficiency.

[0035] The device can be defined as a computing unit or computer, which may take the form of a handheld device, embedded system, or any other hardware-based system capable of executing the described validation mechanism, in particular the disclosed method. The device includes essential components such as a processor unit, which may be a microprocessor, central processing unit (CPU), or application-specific integrated circuit (ASIC) responsible for performing the described steps. It also incorporates a memory unit, which can include both volatile and non-volatile memory, for storing the hierarchical file system, validation counters, and other necessary data. Additionally, the device is equipped with interfaces for communication, such as USB, Ethernet, or wireless communication modules like Wi-Fi or Bluetooth, enabling interaction with external systems or networks. These components collectively enable the implementation of the described validation process, ensuring that the device operates effectively in diverse application scenarios. The above-described with reference to the method applies analogously to the device and vice versa.

[0036] The above-described can be summarized in other words and in a possible more specific embodiment of the disclosure as described below, wherein the following description is not to be construed as limiting to the disclosure.

[0037] By introducing a global ‘Validity Counter’ (in short VC), we can validate changes by just incrementing this only counter while the changes are already correctly linked into the file system. Every data block which should be part of the validation process (transaction) requires a ‘Validity Value’ (in short VV). If the VV is equal or less (<=) compared to the VC the data block is valid. The higher the VV the more actual is the change, therefore the highest VV in the validity range is the valid one. Every update shall set the VV to VC+1, which makes the update invalid at this point in time. Once all updates are performed only the VC need to be incremented to validate all changes.

[0038] On embedded devices it is a common approach to write the new data into a shadow image to prevent problem during tearing. An in-place update is not possible with the validation method, if the previous data should not be destroyed.

[0039] Deletion is simply, by just updated the VV of the data block to an invalid value. The system can define their own VV to be invalid (e.g., for 1 Byte values ‘00h’ or ‘FFh’). Keeping the deleted data block in the file system would allow to re-activate it again at a later point in time.

[0040] Once the VC reached its limit the whole filesystem needs to be updated, we call this a cleanup procedure. This means the VC and all VVs require an update.

[0041] This can be done in two steps, first the invalid (or outdated) images I data blocks of the whole file system shall get a VV=0. The first step has no influence on the functionality of the validation method. And second, all valid images I data blocks shall get the same value as the VC higher than zero e.g., VV=1 and VC=1.

[0042] In case of an interrupted update procedure, all images or data blocks with VVs > VC can be deleted to make the filesystem consistent. There is no separate protection mechanism or logging mechanism required. If the VC is set to a specific value, the number of changes can be limited. For robustness reason (e.g., corruption or tearing protection) the file system can implement multiple VCs where only the highest one is the valid one.

[0043] • All data blocks are maintained directly in the filesystem. No separate management overhead required.

[0044] • Is not restricted by a hierarchical filesystem.

[0045] • Very fast validation of all changes.

[0046] • No scaling problems on the number of pending updates.

[0047] • Can be used to create an atomic transaction mechanism.

[0048] • Already applied changes survive a power loss and can be validated later.

[0049] • The validation does not need to be related to the last transaction.

[0050] Furthermore, a computer program is provided, comprising instructions which, when executed by a computer, cause the computer to perform or partially perform the method described above. The program code of the computer program may be in any code format, particularly in a code suitable for controlling motor vehicles. The above-described with reference to the control device, the motor vehicle, and the method applies analogously to the computer program and vice versa.

[0051] Additionally, a computer-readable medium, particularly a computer-readable storage medium, is provided. The computer-readable medium comprises instructions which, when executed by a computer, cause the computer to perform or partially perform the method described above. This means that a computer-readable medium can be provided which includes the computer program as defined above. The computer-readable medium may be any digital data storage device, such as a USB stick, a hard drive, a CD-ROM, an SD card, or an SSD card (or SSD drive / SSD hard drive).

[0052] The computer program does not necessarily have to be stored on such a computer- readable storage medium to be made available to the motor vehicle; it can also be obtained via the Internet or from other external sources. The above-described with reference to the method, the control device, the computer program, and the motor vehicle applies analogously to the computer-readable medium and vice versa.

[0053] The disclosure also encompasses combinations of the features of the described embodiments. Thus, the disclosure also includes implementations that feature a combination of the characteristics of several described embodiments, provided the embodiments are not described as being mutually exclusive.

[0054] Brief Descriptions of the Drawings

[0055] In the following, the disclosure will further be described with reference to exemplary embodiments illustrated in the figures, in which:

[0056] Fig. 1 schematically shows a device for validating changes in a hierarchical file system;

[0057] Fig. 2 schematically shows a flow chart of the method for validating changes in a hierarchical file system, and

[0058] Fig. 3 schematically shows an implementation example for a validating using an embodiment of the disclosed method;

[0059] Fig. 4 schematically shows a further implementation example for a validating using an embodiment of the disclosed method, and

[0060] Fig. 5 schematically shows a further implementation example for a validating using an embodiment of the disclosed method.

[0061] Detailed Description

[0062] In the following description, for purposes of explanation and not limitation, specific details are set forth, in order to provide a thorough understanding of the current disclosure. It will be apparent to one skilled in the art that the current disclosure may be practiced in other embodiments that depart from these specific details. For example, the skilled artisan will appreciate that the current disclosure may be practiced with any application for different functionalities or for different computing entities.

[0063] Figure 1 illustrates a device 10 configured to validate changes in a hierarchical file system 20. The device 10 comprises a processor unit 11 and a memory unit 12, which communicate with each other. The memory unit 12 serves as an example for storing the hierarchical file system 20 and may include various storage mediums such as a smart card. In cases where the memory unit 12 is a smart card, the device 10 further includes a reader or further interface for accessing and validating the data stored on the smart card. The hierarchical file system 20 is maintained within the memory unit 12, facilitating the storage and retrieval of data blocks necessary for system operations.

[0064] The processor unit 11 is configured to execute multiple operations to ensure data consistency and reliability within the hierarchical file system 20. A global validation counter (VC) is provided and associated with a validation value (VV) assigned to each data block stored in the hierarchical file system 20. The validation value of a data block is set to a value greater than the current VC while the data block is being updated. This ensures that the data block cannot be prematurely marked as valid until the update operation is completed. The processor unit 11 validates all updated data blocks by incrementing the VC, thereby marking all validation values that are less than or equal to the VC as valid. This process ensures the integrity of previously updated data blocks and prevents inconsistencies.

[0065] In the event of an interruption during an update operation, the processor unit 11 identifies and marks all data blocks whose validation values exceed the current VC as invalid. This feature safeguards the consistency of the hierarchical file system 20, even in scenarios where updates are not completed. The processor unit 11 also includes a cleanup mechanism, which sets all invalid or outdated validation values to a predefined invalid state. During cleanup, the processor resets all valid validation values and the global validation counter to an initial state, optimizing the system for subsequent operations and enhancing the efficiency of memory management.

[0066] The processor unit 11 enables additional features to improve the reliability and functionality of the system. During an update of a data block, the processor retains the old validation value until the write operation is fully completed, preventing errors caused by partially written data. The processor performs validation operations atomically by incrementing the validation counter, allowing multiple independent changes to be validated simultaneously. This atomic operation ensures that the hierarchical file system 20 remains consistent even during concurrent update processes. To support high- frequency write operations, the validation counter is implemented as a multi-byte value, ensuring scalability for systems with large data storage requirements. The memory unit 12, which contains the hierarchical file system 20, may also store shadow copies of validation values. Before integrating a new validation value into the file system, the processor unit 11 writes the value to a shadow copy to protect against data loss in the event of an interruption. The system can manage multiple shadow copies, enabling the processor unit 11 to maintain a revision history for data blocks. The validation counter allows the processor to select a specific shadow copy as valid, supporting rollback functionality and enabling the selection of prior states of the data for enhanced reliability.

[0067] The device 10 for validating changes in a hierarchical file system is also suitable for performing the following method with reference to Figure 2.

[0068] Figure 2 schematically shows a flow chart of the method 100 for validating changes in a hierarchical file system. The method 100 comprises several method steps. The Order of processing the method step can be adjusted if it technically possible.

[0069] In a first step 110 of the method 100, a global validation counter, VC, and a corresponding validation value, VV, for each data block in the hierarchical file system 20 are provided. It enables a precise tracking and validation of the state of each data block. This mechanism ensures that each data block can be individually associated with a specific validation status relative to the global counter. It facilitates consistent management of updates, minimizes the risk of data corruption, and allows for efficient identification of valid and invalid data blocks during operations, particularly in scenarios involving concurrent updates or system interruptions.

[0070] In a further step 120, the VV of a data block is set to a value greater than the current value of the VC while the data block is being updated. This ensures that the data block cannot be prematurely validated before the update process is fully completed, thereby preventing inconsistencies in the hierarchical file system 20. It also enables clear differentiation between data blocks undergoing updates and those that are already valid, enhancing the reliability of the validation process.

[0071] In a further step 130, all updated data blocks are validated by incrementing the value of the VC, thereby marking all VVs that are less than or equal to the VC as valid. This ensures a consistent and efficient mechanism for confirming the integrity of updated data blocks while maintaining synchronization across the hierarchical file system. It reduces the likelihood of data errors and simplifies the validation process by allowing multiple data blocks to be marked as valid in a single operation.

[0072] Figure 3 schematically shows an implementation example for a validating using an embodiment of the disclosed method, in particular a flow in three steps of an implementation example for a validating. Figure 3 illustrates a stepwise process of validating changes in a hierarchical file system 20 using the method 100. The process involves maintaining data consistency and preventing data loss by employing a shadow image approach, which avoids direct in-place updates. This is particularly important for embedded devices, where tearing or power interruptions could lead to incomplete or corrupted updates.

[0073] Initially, the global validation counter (VC) is set to a specific value, such as VC = 1. The data block starts with an initial validation value (VV) of 0, indicating that it has not yet been updated. During the update process, the new data is written to a shadow image, and the validation value (VV) of the data block is temporarily set to a value greater than the current VC, such as VV = 2. This ensures that the original data remains intact and accessible until the update is fully completed.

[0074] Once the update is finalized, the global validation counter (VC) is incremented to VC = 2, marking all validation values less than or equal to the VC as valid.

[0075] Figure 4 schematically shows a further implementation example for a validating using an embodiment of the disclosed method, in particular a flow in three steps of an implementation example for a validating. Figure 4 illustrates the update process using a shadow image within the hierarchical file system 20, demonstrating how data consistency and integrity are maintained throughout the update operation. This process is especially advantageous for embedded devices where in-place updates are not feasible, as they could destroy previous data and lead to data loss in the event of interruptions such as tearing or power failures.

[0076] Initially, the global validation counter (VC) is set to VC = 1 , and the data block holds a validation value (VV) of 0, designating the block as valid. A shadow image is used to store updates separately from the original data. At this stage, the shadow image has its own initial validation value (VV = 0), ensuring the validity of the existing data remains unaffected. During the update process, the shadow image is modified, and its validation value is updated to a value greater than the current global validation counter. In this example, the validation value of the shadow image is updated to VV = 2. The original data block and its validation value (VV = 0) remain intact and valid throughout the update. This approach ensures that the original data can be accessed or reverted to if necessary, preventing the destruction of critical information during the update process.

[0077] After the shadow image is fully updated, the global validation counter is incremented to VC = 2. At this point, the shadow image is integrated into the hierarchical file system 20 as the new valid data. The validation value of the shadow image (VV = 2) is now less than or equal to the updated global validation counter, marking the shadow image as valid. The system ensures that only one version of the data — either the original or the updated version — remains valid at any given time.

[0078] This use of a shadow image allows for rollback to the previous state if an interruption occurs during the update. By maintaining separate validation values for the data block and the shadow image, the system can identify and validate the most recent completed state, ensuring data reliability. Writing the validation value (VV) to the shadow image before its integration prevents data loss and enhances the safety of the update process. The atomic increment of the global validation counter (VC) further ensures that multiple updates can be validated simultaneously, streamlining the process and improving efficiency.

[0079] This method is particularly effective for embedded devices, where environmental and hardware constraints demand robust and reliable data management solutions. By isolating the update process within the shadow image, the hierarchical file system 20 maintains consistency and prevents corruption, even in scenarios involving frequent or concurrent updates.

[0080] Figure 5 schematically shows a further implementation example for a validating using an embodiment of the disclosed method, in particular a flow in three steps of an implementation example for a validating. Figure 5 illustrates the creation of additional data blocks at different hierarchical levels within an example hierarchical file system 20. The process demonstrates how new data blocks, such as Data5 and Data6, are added while maintaining consistency and validation through the use of a global validation counter (VC) and corresponding validation values (VV). Initially, the hierarchical file system 20 is organized under a root directory with data blocks Datal, Data2, Data3, and Data4 stored at various levels. Each data block has an initial validation value (VV = 0), and the global validation counter is set to VC = 1 , indicating that all current data blocks are valid and synchronized with the validation counter.

[0081] In the next step, new data blocks, Data5 and Data6, are created. Data5 is added at the same hierarchical level as Datal, Data2, and Data3, while Data6 is created at the same level as Data4, under a folder directory. During the creation process, the validation values for the newly added data blocks are set to a value greater than the current validation counter (VV = 2). This ensures that the newly created data blocks remain invalid until the creation process is finalized. The existing data blocks and their validation values are left unchanged during this operation, allowing uninterrupted access to the valid data.

[0082] Once the creation of Data5 and Data6 is complete, the global validation counter is incremented to VC = 2. At this stage, the validation values of Data5 and Data6 (VV = 2) are equal to the updated global validation counter, marking them as valid. All other data blocks with validation values less than or equal to VC (e.g., Datal , Data2, Data3, and Data4) remain valid. This incremental approach ensures that the new data blocks are fully validated and integrated into the file system without disrupting the consistency of the existing data.

[0083] This method supports the hierarchical structure of the file system by allowing the creation of new data blocks at any level without affecting the integrity of other levels. The use of the validation counter and validation values ensures that changes are atomically tracked and validated, enabling efficient handling of updates in systems with complex hierarchical structures. By managing the hierarchical levels independently, the method improves scalability and reliability for file systems in embedded devices or environments requiring high data integrity. Reference Numerals

[0084] 100 Method

[0085] 110-130 Method steps 10 Device

[0086] 11 Processor

[0087] 12 Memory unit

[0088] 20 hierarchical file system

Claims

AMENDED CLAIMS received by the International Bureau on 03 September 2025 (03.09.2025)1 . Method (100) for validating changes in a hierarchical file system (20), comprising the steps:- Providing (110) a global validation counter, VC, and a corresponding validation value, VV, for each data block in the hierarchical file system (20);- Setting (120) the VV of a data block to a value greater than the current value of the VC while the data block is being updated; and- Validating (130) all updated data blocks by incrementing the value of the VC, thereby marking all VVs that are less than or equal to the VC as valid characterized in that during the update of the data block, new data is written to a temporary storage area of a shadow copy while retaining the previous validation value (VV); and the validation value (VV) is updated only upon successful completion of the write operation, thereby preventing data blocks from being marked valid if the update was interrupted or incomplete.

2. Method (100) according to the direct preceding claim, wherein the hierarchical file system (20) comprises multiple hierarchical levels, and the validation is performed independently of the hierarchical level.

3. Method (100) according to any of the preceding claims, wherein, in the event of an interruption during the update of a data block, all data blocks whose VV is greater than the current VC are marked as invalid to ensure the consistency of the hierarchical file system (20).

4. Method (100) according to any of the preceding claims, wherein a plurality of global validation counters is implemented, and the highest VC value is considered valid.

5. Method (100) according to any of the preceding claims, wherein the method (100) further includes a cleanup step, the cleanup step comprising:- Setting all invalid VVs or outdated VVs to a predefined invalid value; and- Resetting all valid VVs and the VC to an initial value.

6. Method (100) according to any of the preceding claims, wherein a data block is reactivated after deletion by resetting its VV to a valid value.

7. Method (100) according to any of the preceding claims, wherein, during an update of the data block, the old VV is retained until the write operation is fully completed to prevent errors caused by inconsistent data.

8. Method (100) according to any of the preceding claims, wherein the validation is performed atomically by incrementing the value of the VC, enabling multiple independent changes to be validated simultaneously.

9. Method (100) according to any of the preceding claims, wherein the VC is a multibyte value to support a high number of write operations.

10. Method according to any of the preceding claims, wherein the VV of a data block is written to the shadow copy before the new VV is integrated into the file system to prevent data loss during an interruption.

11. Method according to the direct preceding claim, wherein a plurality of shadow copies is created for each data block, enabling a revision history by using the validation counter (VC) to control which shadow copy is considered valid.

12. Method according to the direct preceding claim, wherein the validation counter is configured to select a previous shadow copy as valid, thereby enabling a step back in the revision history.

13. Device (10) for validating changes in a hierarchical file system (20), comprising: a processor unit (11) configured to:- Provide a global validation counter, VC, and a corresponding validation value, VV, for each data block in the hierarchical file system (20);- Set the VV of a data block to a value greater than the current value of the VC while the data block is being updated; and- Validate all updated data blocks by incrementing the value of the VC, thereby marking all VVs that are less than or equal to the VC as valid characterized in thatduring the update of the data block, new data is written to a temporary memory region of a shadow copy while retaining the previous validation value (VV); and the validation value (VV) is updated only upon successful completion of the write operation, thereby preventing data blocks from being marked valid if the update was interrupted or incomplete.

14. Computer program comprising instructions which, when executed by a computer, cause the computer to carry out the method according to the any of the preceding method claims.

Images