Embedded configuration update and compressed packet atomic write back method and system

Abstract

The application relates to the technical field of semiconductor test program management, and discloses an embedded configuration updating and compressed package atomic backwriting method and system, which comprises the following steps: obtaining a customer identification code and a batch identification code and performing a matching operation on the customer identification code; constructing a complete access path of a check configuration file; opening the check configuration file in a streaming reading mode and extracting configuration entries one by one; performing a field prefix matching operation on the extracted configuration entries, replacing a check code field value in a target configuration entry with the batch identification code, and backwriting the file content to the check configuration file after reconstruction; creating a temporary storage space and establishing a temporary compressed package storage path; compressing a program directory into a temporary compressed package; calling an atomic path redirection interface to redirect the storage path of the temporary compressed package to the storage path of an original compressed package; and removing the temporary storage space. The application can significantly improve the reliability of the compressed package backwriting operation.

Description

Technical Field

[0001] This invention relates to the field of semiconductor test program management technology, specifically to an embedded configuration update and compressed package atomic write-back method and system. Background Technology

[0002] In the semiconductor testing process, to ensure that test data from different batches does not cross-contaminate, the test equipment requires that the checksum field value in the verification configuration file embedded in the test program package be consistent with the current batch number issued by the manufacturing execution system. Before each new batch test, it is necessary to ensure that the checksum in the compressed package matches the current batch number.

[0003] In existing technologies, operators typically update checksums manually: first, the test program archive is decompressed, then the checksum field in the configuration file in the decompressed directory is manually modified, and finally the modified content is recompressed into a new archive. This entire process relies on manual intervention, resulting in lengthy switching times for each batch. More importantly, the archive write-back process suffers from a serious technical flaw: existing solutions directly overwrite the original archive with the recompressed archive. The compression operation itself is time-consuming and affected by system resource status. If a process is abnormally interrupted, storage space is insufficient, or a file system error occurs during the overwrite process, the original archive will be corrupted midway and cannot be recovered. This flaw directly renders the test program unusable in actual production, requiring a complete archive to be retrieved from a backup server, causing prolonged shutdowns of the test production line. Summary of the Invention

[0004] To solve the above technical problems, the following technical solution is proposed: The embedded configuration update and compressed package atomic write-back method includes the following steps: S1: In response to the configuration verification process triggered by the current test task, obtain the customer identification code and batch identification code corresponding to the current test task, and perform a matching operation on the customer identification code according to the preset adapted customer set; if the customer identification code matches the adapted customer set, execute the subsequent configuration update steps; S2: Based on the target storage path and program name of the current test program, construct the complete access path of the verification configuration file, and perform an existence probe on the complete access path to confirm the existence status of the verification configuration file in the storage medium; S3: After confirming that the verification configuration file exists, open the verification configuration file in streaming mode and extract each configuration entry one by one according to the physical storage order of the configuration entries; S4: Perform a field prefix matching operation on the starting field of each extracted configuration entry to identify whether the configuration entry carries a checksum field identifier; when a target configuration entry carrying a checksum field identifier is identified, replace the original checksum field value in the target configuration entry with a batch identifier, and activate the configuration update flag; write all configuration entries after the replacement operation into the cache container in the original reading order, and when reconstructing the contents of the cache container into the target file content, perform the process of not appending a newline character on the first configuration entry in the cache container, and insert a newline character between adjacent configuration entries; S5: When the configuration update flag is active, write back the contents of the target file in the cache container to the verification configuration file to trigger the compressed package write-back process; S6: After the compressed package write-back process is triggered, a temporary storage space independent of the original compressed package storage path is created in the storage root directory where the target storage path is located, and a temporary compressed package storage path is established in the temporary storage space. S7: Using the current test program directory as the compression source and the temporary compressed package storage path as the compression target, perform an archive compression operation to compress the program directory into a temporary compressed package and store the temporary compressed package in the temporary compressed package storage path. S8: After confirming that the temporary compressed package is in a fully readable state, call the atomic path redirection interface of the underlying file system to redirect the storage path of the temporary compressed package to the original storage path of the original compressed package. During the redirection process, enable the replacement strategy of overwriting existing files so that the original compressed package is completely replaced by the temporary compressed package in a single file system operation transaction. S9: Remove temporary storage space after the atomic path redirection operation is completed.

[0005] As a preferred embodiment of the present invention, step S6 involves creating a temporary storage space independent of the original compressed package storage path in the root directory of the target storage path, which specifically includes the following sub-steps: Generate a universally unique identifier in the storage root directory. The universally unique identifier has a one-to-one correspondence with the current write-back process. Using a universally unique identifier as the temporary directory name, a temporary directory creation operation is performed in the storage root directory to form a temporary directory that can only be exclusively accessed by the current write-back process; Obtain the filename of the original compressed package, and concatenate the filename with the path of the temporary directory within the temporary directory to form the temporary compressed package storage path. The temporary compressed package storage path and the original storage path of the original compressed package are independent of each other at the file system level.

[0006] As a preferred embodiment of the present invention, step S5, which involves writing back the target file content in the cache container to the verification configuration file, specifically includes the following sub-steps: Open the file output stream corresponding to the verification configuration file, and apply an exclusive write lock to the verification configuration file while the file output stream is open. The exclusive write lock is used to prevent other processes besides the current write-back process from accessing the verification configuration file during the write process. The contents of the target file in the cache container are written to the verification configuration file in a synchronous blocking manner through the file output stream. After the write operation is complete, release the exclusive write lock and close the file output stream, restoring the verification configuration file to a state accessible to other processes.

[0007] As a preferred embodiment of the present invention, step S4, in which the original check code field value in the target configuration entry is replaced with a batch identification code, specifically includes the following sub-steps: Locate the start and end positions of the checksum field within the string range of the target configuration entry; Extract the field value range defined by the start and end positions of the field, and remove all original field values ​​within the field value range; Write the batch identification code within the same field value range defined by the start and end positions of the field, keeping the remaining characters in the target configuration entry unchanged except for the check code field value.

[0008] As a preferred embodiment of the present invention, the archiving and compression operation in step S7 further includes an exception interruption handling process, specifically including the following sub-steps: Continuously monitor the process liveness status of the compression process during the archive compression operation; When an interrupt event of abnormal termination of the compression process is captured during the monitoring process, the interrupt location information corresponding to the interrupt event is obtained and the interrupt location information is recorded in the error log; Based on the interruption location information, identify the partially generated compressed files in the temporary storage space, perform deletion operations on the partially generated compressed files, restore the temporary storage space to its initial state before the archive compression operation, and terminate the current write-back process.

[0009] As a preferred embodiment of the present invention, step S3 involves opening the verification configuration file in a streaming manner and extracting each configuration entry one by one according to the physical storage order of the configuration entries. Specifically, this includes the following sub-steps: Using the file encoding format of the verification configuration file as the parsing benchmark, open the byte input stream corresponding to the verification configuration file; Read byte by byte starting from the beginning of the byte input stream. When a line terminator is encountered, extract all bytes read before the line terminator as a complete configuration entry. After extracting the current configuration entry, continue reading from the beginning of the next byte of the byte input stream, repeating the configuration entry extraction operation until the end of the byte input stream is reached.

[0010] As a preferred embodiment of the present invention, after calling the atomic path redirection interface of the underlying file system to redirect the storage path of the temporary compressed package to the original storage path of the original compressed package in step S8, the method further includes an atomic replacement result confirmation process, which specifically includes the following sub-steps: Read the file attribute information of the original compressed package in the original storage path. The file attribute information includes file size, file modification timestamp, and file system inode identifier. Obtain the historical file attribute information of the temporary compressed package before the atomic path redirection operation is executed, and perform a consistency check between the file attribute information of the original compressed package and the historical file attribute information; If the file size, file modification timestamp, and file system inode identifier all match, confirm that the atomic path redirection operation was successful and generate a success confirmation record to be written to the log.

[0011] As a preferred embodiment of the present invention, step S1, which involves performing a matching operation on the customer identification code based on a preset set of compatible customers, specifically includes the following sub-steps: Extract each preset customer identification code sequentially from the preset set of compatible customers; Perform a string equality comparison between the customer identification code and the currently extracted preset customer identification code; If the customer identification code is equal to any one of the preset customer identification codes, it is determined that the customer identification code matches the set of suitable customers, and an adaptation pass flag is generated. The adaptation pass flag is used to enable the execution of subsequent configuration update steps. If the customer identification code is not equal to any of the preset customer identification codes, it is determined that the customer identification code does not match the set of suitable customers, and the current configuration verification process is terminated.

[0012] An embedded configuration update and compressed package atomic write-back system for performing any of the methods described above, comprising: The customer adaptation trigger module is used to respond to the configuration verification process triggered by the current test task, obtain the customer identification code and batch identification code corresponding to the current test task, and perform a matching operation on the customer identification code according to the preset adapted customer set; if the customer identification code matches the adapted customer set, the subsequent configuration update process is triggered. The path construction and detection module is used to construct the complete access path of the verification configuration file based on the target storage path and program name where the current test program is located, and to perform an existence detection on the complete access path to confirm the existence status of the verification configuration file in the storage medium. The streaming read module is used to open the verification configuration file in streaming mode after confirming that the verification configuration file exists, and extract each configuration entry one by one according to the physical storage order of the configuration entries. The configuration entry replacement and format preservation module performs a field prefix matching operation on the starting field of each extracted configuration entry to identify whether the configuration entry carries a checksum field identifier. When a target configuration entry carrying a checksum field identifier is identified, the original checksum field value in the target configuration entry is replaced with a batch identification code, and the configuration update flag is activated. All configuration entries after the replacement operation are written to the cache container in the original reading order. When reconstructing the contents of the cache container into the target file content, the first configuration entry in the cache container is processed to not add a newline character, and a newline character is inserted between adjacent configuration entries. Under the condition that the configuration update flag is active, the target file content in the cache container is written back to the verification configuration file to trigger the compressed package write-back process. The temporary space creation module is used to create a temporary storage space independent of the original compressed package storage path in the storage root directory where the target storage path is located after the compressed package write-back process is triggered, and to establish a temporary compressed package storage path in the temporary storage space. The archive compression execution module is used to perform archive compression operations with the current test program directory as the compression source and the temporary compressed package storage path as the compression target, compressing the program directory into a temporary compressed package and storing the temporary compressed package in the temporary compressed package storage path; The atomic path redirection module is used to call the atomic path redirection interface of the underlying file system after confirming that the temporary compressed package is in a completely readable state, redirect the storage path of the temporary compressed package to the original storage path of the original compressed package, and enable the replacement strategy of overwriting existing files during the redirection process, so that the original compressed package is completely replaced by the temporary compressed package in a single file system operation transaction. The space reclamation module is used to remove temporary storage space after an atomic path redirection operation is completed.

[0013] As a preferred embodiment of the present invention, the system further includes: The write lock control module is used to open the file output stream corresponding to the verification configuration file during the process of the configuration entry replacement and format preservation module writing back the target file content in the cache container to the verification configuration file. During the opening of the file output stream, an exclusive write lock is applied to the verification configuration file. The exclusive write lock is used to prevent other processes besides the current write-back process from accessing the verification configuration file during the write process. The target file content in the cache container is written to the verification configuration file in a synchronous blocking manner through the file output stream. After the write operation is completed, the exclusive write lock is released and the file output stream is closed, so that the verification configuration file is restored to a state accessible to other processes. The exception interruption handling module is used to continuously monitor the process life status of the compression process during the archiving and compression operation performed by the archiving and compression execution module; when an interruption event of abnormal termination of the compression process is captured during the monitoring process, the interruption location information corresponding to the interruption event is obtained and the interruption location information is recorded to the error log; based on the interruption location information, the module identifies some compressed files that have been generated in the temporary storage space, performs deletion operations on some compressed files, restores the temporary storage space to the initial state before the archiving and compression operation is performed, and terminates the current write-back process.

[0014] The present invention has the following technical effects: 1. This invention uses an atomic path redirection mechanism to transfer the temporary compressed package to the path where the original compressed package is located, so that the replacement operation is completed in a single indivisible transaction at the underlying file system level. This fundamentally eliminates the risk of the original compressed package being corrupted due to interruption during the replacement process and significantly improves the reliability of the compressed package write-back operation.

[0015] 2. By creating an independent temporary storage space, this invention enables the compression operation to be performed in a temporary space completely independent of the original compressed package storage path. Any abnormalities during the compression process will not affect the original compressed package, further ensuring the security of the original data.

[0016] 3. This invention updates the checksum by reading line by line in a streaming manner and replacing field values ​​in place. When reconstructing the file content, it maintains the format by not adding a newline character to the first configuration entry and inserting newline characters between adjacent configuration entries. This ensures that the original format structure of the verification configuration file is completely preserved and avoids test machine parsing failure due to format changes.

[0017] 4. This invention uses a pre-verification mechanism for customer adaptation to trigger the complete configuration update and write-back process only when the customer identification code matches the set of adapted customers. Test tasks for other customer codes are skipped directly, effectively avoiding unnecessary file operation overhead and improving the overall system efficiency in multi-customer parallel testing scenarios.

[0018] 5. This invention uses a combination of exclusive write locks and synchronous blocking writes to write the configuration file content back to the verification configuration file, preventing other processes from accessing the file during the writing process, thus ensuring the atomicity and data integrity of the configuration file write operation.

[0019] 6. This invention uses a multi-dimensional result confirmation process after atomic replacement to perform consistency verification on the replacement result from three dimensions: file size, file modification timestamp, and file system inode identifier, and generates confirmation records to be written to the log, providing reliable data support for subsequent operation traceability and auditing. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the overall process of the embedded configuration update and compressed package atomic write-back method of the present invention; Figure 2 This is a structural framework diagram of the embedded configuration update and compressed package atomic write-back system of the present invention. Detailed Implementation

[0021] Example 1 like Figure 1 As shown, this invention provides an embedded configuration update and compressed package atomic write-back method, including the following steps: S1: In response to the configuration verification process triggered by the current test task, obtain the customer identification code and batch identification code corresponding to the current test task, and perform a matching operation on the customer identification code according to the preset adapted customer set; if the customer identification code matches the adapted customer set, execute the subsequent configuration update steps; S2: Based on the target storage path and program name of the current test program, construct the complete access path of the verification configuration file, and perform an existence probe on the complete access path to confirm the existence status of the verification configuration file in the storage medium; S3: After confirming that the verification configuration file exists, open the verification configuration file in streaming mode and extract each configuration entry one by one according to the physical storage order of the configuration entries; S4: Perform a field prefix matching operation on the starting field of each extracted configuration entry to identify whether the configuration entry carries a checksum field identifier; when a target configuration entry carrying a checksum field identifier is identified, replace the original checksum field value in the target configuration entry with a batch identifier, and activate the configuration update flag; write all configuration entries after the replacement operation into the cache container in the original reading order, and when reconstructing the contents of the cache container into the target file content, perform the process of not appending a newline character on the first configuration entry in the cache container, and insert a newline character between adjacent configuration entries; S5: When the configuration update flag is active, write back the contents of the target file in the cache container to the verification configuration file to trigger the compressed package write-back process; S6: After the compressed package write-back process is triggered, a temporary storage space independent of the original compressed package storage path is created in the storage root directory where the target storage path is located, and a temporary compressed package storage path is established in the temporary storage space. S7: Using the current test program directory as the compression source and the temporary compressed package storage path as the compression target, perform an archive compression operation to compress the program directory into a temporary compressed package and store the temporary compressed package in the temporary compressed package storage path. S8: After confirming that the temporary compressed package is in a fully readable state, call the atomic path redirection interface of the underlying file system to redirect the storage path of the temporary compressed package to the original storage path of the original compressed package. During the redirection process, enable the replacement strategy of overwriting existing files so that the original compressed package is completely replaced by the temporary compressed package in a single file system operation transaction. S9: Remove temporary storage space after the atomic path redirection operation is completed.

[0022] Furthermore, step S6 involves creating a temporary storage space independent of the original compressed file storage path in the root directory of the target storage path. This includes the following sub-steps: Generate a universally unique identifier in the storage root directory. The universally unique identifier has a one-to-one correspondence with the current write-back process. Using a universally unique identifier as the temporary directory name, a temporary directory creation operation is performed in the storage root directory to form a temporary directory that can only be exclusively accessed by the current write-back process; Obtain the filename of the original compressed package, and concatenate the filename with the path of the temporary directory within the temporary directory to form the temporary compressed package storage path. The temporary compressed package storage path and the original storage path of the original compressed package are independent of each other at the file system level.

[0023] Furthermore, step S5 involves writing back the contents of the target file in the cache container to the verification configuration file, specifically including the following sub-steps: Open the file output stream corresponding to the verification configuration file, and apply an exclusive write lock to the verification configuration file while the file output stream is open. The exclusive write lock is used to prevent other processes besides the current write-back process from accessing the verification configuration file during the write process. The contents of the target file in the cache container are written to the verification configuration file in a synchronous blocking manner through the file output stream. After the write operation is complete, release the exclusive write lock and close the file output stream, restoring the verification configuration file to a state accessible to other processes.

[0024] Furthermore, step S4 replaces the original checksum field value in the target configuration entry with a batch identification code, specifically including the following sub-steps: Locate the start and end positions of the checksum field within the string range of the target configuration entry; Extract the field value range defined by the start and end positions of the field, and remove all original field values ​​within the field value range; Write the batch identification code within the same field value range defined by the start and end positions of the field, keeping the remaining characters in the target configuration entry unchanged except for the check code field value.

[0025] Furthermore, the archiving and compression operation in step S7 also includes an exception handling process, specifically comprising the following sub-steps: Continuously monitor the process liveness status of the compression process during the archive compression operation; When an interrupt event of abnormal termination of the compression process is captured during the monitoring process, the interrupt location information corresponding to the interrupt event is obtained and the interrupt location information is recorded in the error log; Based on the interruption location information, identify the partially generated compressed files in the temporary storage space, perform deletion operations on the partially generated compressed files, restore the temporary storage space to its initial state before the archive compression operation, and terminate the current write-back process.

[0026] Furthermore, step S3 involves opening the verification configuration file in streaming mode and extracting each configuration entry one by one according to the physical storage order of the configuration entries. This specifically includes the following sub-steps: Using the file encoding format of the verification configuration file as the parsing benchmark, open the byte input stream corresponding to the verification configuration file; Read byte by byte starting from the beginning of the byte input stream. When a line terminator is encountered, extract all bytes read before the line terminator as a complete configuration entry. After extracting the current configuration entry, continue reading from the beginning of the next byte of the byte input stream, repeating the configuration entry extraction operation until the end of the byte input stream is reached.

[0027] Furthermore, after step S8 calls the atomic path redirection interface of the underlying file system to redirect the storage path of the temporary compressed package to the original storage path of the original compressed package, it also includes an atomic replacement result confirmation process, which specifically includes the following sub-steps: Read the file attribute information of the original compressed package in the original storage path. The file attribute information includes file size, file modification timestamp, and file system inode identifier. Obtain the historical file attribute information of the temporary compressed package before the atomic path redirection operation is executed, and perform a consistency check between the file attribute information of the original compressed package and the historical file attribute information; If the file size, file modification timestamp, and file system inode identifier all match, confirm that the atomic path redirection operation was successful and generate a success confirmation record to be written to the log.

[0028] Furthermore, in step S1, a matching operation is performed on the customer identification code according to the preset set of compatible customers, which specifically includes the following sub-steps: Extract each preset customer identification code sequentially from the preset set of compatible customers; Perform a string equality comparison between the customer identification code and the currently extracted preset customer identification code; If the customer identification code is equal to any one of the preset customer identification codes, it is determined that the customer identification code matches the set of suitable customers, and an adaptation pass flag is generated. The adaptation pass flag is used to enable the execution of subsequent configuration update steps. If the customer identification code is not equal to any of the preset customer identification codes, it is determined that the customer identification code does not match the set of suitable customers, and the current configuration verification process is terminated.

[0029] like Figure 2 As shown, the present invention also provides an embedded configuration update and compressed package atomic write-back system for performing any of the above methods, including: The customer adaptation trigger module is used to respond to the configuration verification process triggered by the current test task, obtain the customer identification code and batch identification code corresponding to the current test task, and perform a matching operation on the customer identification code according to the preset adapted customer set; if the customer identification code matches the adapted customer set, the subsequent configuration update process is triggered. The path construction and detection module is used to construct the complete access path of the verification configuration file based on the target storage path and program name where the current test program is located, and to perform an existence detection on the complete access path to confirm the existence status of the verification configuration file in the storage medium. The streaming read module is used to open the verification configuration file in streaming mode after confirming that the verification configuration file exists, and extract each configuration entry one by one according to the physical storage order of the configuration entries. The configuration entry replacement and format preservation module performs a field prefix matching operation on the starting field of each extracted configuration entry to identify whether the configuration entry carries a checksum field identifier. When a target configuration entry carrying a checksum field identifier is identified, the original checksum field value in the target configuration entry is replaced with a batch identification code, and the configuration update flag is activated. All configuration entries after the replacement operation are written to the cache container in the original reading order. When reconstructing the contents of the cache container into the target file content, the first configuration entry in the cache container is processed to not add a newline character, and a newline character is inserted between adjacent configuration entries. Under the condition that the configuration update flag is active, the target file content in the cache container is written back to the verification configuration file to trigger the compressed package write-back process. The temporary space creation module is used to create a temporary storage space independent of the original compressed package storage path in the storage root directory where the target storage path is located after the compressed package write-back process is triggered, and to establish a temporary compressed package storage path in the temporary storage space. The archive compression execution module is used to perform archive compression operations with the current test program directory as the compression source and the temporary compressed package storage path as the compression target, compressing the program directory into a temporary compressed package and storing the temporary compressed package in the temporary compressed package storage path; The atomic path redirection module is used to call the atomic path redirection interface of the underlying file system after confirming that the temporary compressed package is in a completely readable state, redirect the storage path of the temporary compressed package to the original storage path of the original compressed package, and enable the replacement strategy of overwriting existing files during the redirection process, so that the original compressed package is completely replaced by the temporary compressed package in a single file system operation transaction. The space reclamation module is used to remove temporary storage space after an atomic path redirection operation is completed.

[0030] Furthermore, the system also includes: The write lock control module is used to open the file output stream corresponding to the verification configuration file during the process of the configuration entry replacement and format preservation module writing back the target file content in the cache container to the verification configuration file. During the opening of the file output stream, an exclusive write lock is applied to the verification configuration file. The exclusive write lock is used to prevent other processes besides the current write-back process from accessing the verification configuration file during the write process. The target file content in the cache container is written to the verification configuration file in a synchronous blocking manner through the file output stream. After the write operation is completed, the exclusive write lock is released and the file output stream is closed, so that the verification configuration file is restored to a state accessible to other processes. The exception interruption handling module is used to continuously monitor the process life status of the compression process during the archiving and compression operation performed by the archiving and compression execution module; when an interruption event of abnormal termination of the compression process is captured during the monitoring process, the interruption location information corresponding to the interruption event is obtained and the interruption location information is recorded to the error log; based on the interruption location information, the module identifies some compressed files that have been generated in the temporary storage space, performs deletion operations on some compressed files, restores the temporary storage space to the initial state before the archiving and compression operation is performed, and terminates the current write-back process.

[0031] Example 2 This embodiment takes the scenario of customer code T05 and test machine model S100 in a semiconductor testing scenario as an example to describe in detail the complete execution process of the embedded configuration update and compressed package atomic write-back method provided by the present invention.

[0032] The current test task is set to be issued by the MES manufacturing execution system. The customer identification code corresponding to this test task is T05, the batch identification code is LOT20260622001, the name of the current test program is TestPgm_V1.0, and the test program is stored in the local path D:\ProductionOI\programs\. The original compressed package format is zip, and the original compressed package name is TestPgm_V1.0.zip.

[0033] In step S1, after receiving the test task from the MES, the test machine triggers the configuration verification process. The system extracts the customer identification code T05 and the batch identification code LOT20260622001 from the context information of the test task. The system maintains an adapted customer set, which contains three preset customer identification codes: T05, T06, and S01_TL. The system performs string equality comparisons between the extracted customer identification code T05 and each preset customer identification code in the adapted customer set. The comparison result shows that T05 is equal to the T05 in the set. Therefore, the customer identification code T05 matches the adapted customer set, and the system generates an adaptation pass flag, which enables the execution of subsequent configuration update steps.

[0034] In step S2, the system constructs a complete access path for the verification configuration file based on the target storage path D:\ProductionOI\programs\ and the program name TestPgm_V1.0, according to the preset configuration subdirectory hierarchy. The preset configuration subdirectory hierarchy consists of the program directory, the CheckSum subdirectory, and the standard name of the configuration file. The complete access path obtained after concatenation is D:\ProductionOI\programs\TestPgm_V1.0\CheckSum\CheckSum.ini. The system performs an existence detection on this complete access path to confirm that the verification configuration file exists in the storage medium.

[0035] In step S3, the system uses UTF-8 file encoding as the parsing basis, opens the byte input stream corresponding to the verification configuration file CheckSum.ini, and reads byte by byte starting from the beginning of the byte input stream. When a line terminator is encountered, all bytes read before the line terminator are extracted as a complete configuration entry. The content of the verification configuration file CheckSum.ini contains the following configuration entries: the first line configuration entry is CheckSumVersion=1.0, the second line configuration entry is Code=LOT20260622000, and the last line configuration entry is CheckSumEnable=True. The system extracts the three configuration entries in the above physical storage order.

[0036] In step S4, the system performs a field prefix matching operation on the starting field of each extracted configuration entry. For the first configuration entry, CheckSumVersion=1.0, its starting field is CheckSumVersion, which does not match the checksum field identifier Code=, so the system skips this configuration entry. For the next configuration entry, Code=LOT20260622000, its starting field is Code, which matches the checksum field identifier Code=, so the system identifies this configuration entry as the target configuration entry. The system then locates the starting position of the checksum field within the string range of the target configuration entry. The system terminates the field at the position specified after the equals sign, extracts the original field value LOT20260622000 from this range, and removes it entirely. Then, it writes the batch identifier LOT20260622001 into this range, keeping all characters in the target configuration entry unchanged except for the checksum field value (i.e., maintaining the Code= prefix). After the replacement, the system activates the configuration update flag. For the last configuration entry CheckSumEnable=True, whose starting field is CheckSumEnable, which does not match the checksum field identifier, the system skips this configuration entry. The system writes all configuration entries after the replacement operation into the cache container in the original reading order. Specifically, the cache container contains CheckSumVersion=1.0, Code=LOT20260622001, and CheckSumEnable=True sequentially. When reconstructing the target file content from the cache container, the system performs a process of not appending a newline character to the first configuration entry, CheckSumVersion=1.0, inserts a newline character between the first and second configuration entries, and inserts a newline character between the second and third configuration entries. The first line of the reconstructed target file contains `CheckSumVersion=1.0`, the second line contains `Code=LOT20260622001`, and the third line contains `CheckSumEnable=True`. The system maintains this format to ensure that the reconstructed file content is completely consistent with the original configuration file's structure; that is, the first line has no extra line breaks, and each configuration entry is on a separate line. This format maintenance technique prevents parsing errors on the test machine due to changes in the INI file format, ensuring that the verification configuration file can be correctly recognized and loaded by the test machine.

[0037] In step S5, since the configuration update flag is active, the system writes the target file content in the cache container back to the verification configuration file CheckSum.ini. The system first opens the file output stream corresponding to the verification configuration file. During the opening of the file output stream, an exclusive write lock is applied to the verification configuration file. This exclusive write lock is used to prevent any other process besides the current write process from accessing the verification configuration file during the write process, thereby avoiding file content corruption caused by concurrent writes by multiple processes. The system writes the target file content in the cache container to the verification configuration file in a synchronous blocking manner through the file output stream. After the write operation is completed, the system releases the exclusive write lock and closes the file output stream, restoring the verification configuration file to a state accessible to other processes. The synchronous blocking write method ensures that the write operation is completed before returning, avoiding other processes reading incomplete file content when the write operation is not completed. At this point, the Code value in the verification configuration file has been updated from LOT20260622000 to LOT20260622001, and this update operation triggers the compressed package write-back process.

[0038] In step S6, after the compressed package write-back process is triggered, the system creates a temporary storage space independent of the original compressed package storage path under the storage root directory D:\ProductionOI\programs\ where the target storage path is located. The system first generates a universally unique identifier with the value a1b2c3d4e5f6. This identifier has a one-to-one correspondence with the current write-back process. The system uses this universally unique identifier a1b2c3d4e5f6 as the temporary directory name and performs a temporary directory creation operation under the storage root directory D:\ProductionOI\programs\, forming a temporary directory exclusively accessible to the current write-back process. The complete path of this temporary directory is D:\ProductionOI\programs\a1b2c3d4e5f6\. This temporary directory is isolated from the temporary directories of other write-back processes at the file system level, even if multiple test machines are running simultaneously... When performing write-back operations in different batches, there will be no path conflicts between the temporary directories of each write-back process. The system obtains the file name TestPgm_V1.0.zip of the original compressed package, and concatenates the file name with the path of the temporary directory within the temporary directory to form the temporary compressed package storage path D:\ProductionOI\programs\a1b2c3d4e5f6\TestPgm_V1.0.zip. This temporary compressed package storage path is independent of the original compressed package storage path D:\ProductionOI\programs\TestPgm_V1.0.zip at the file system level. Therefore, subsequent compression operations will not affect the original compressed package. The technical effect of this independent temporary storage space creation mechanism is that even if an anomaly occurs during the compression process, the original compressed package will not be affected, fundamentally avoiding the damage of the original compressed package due to compression failure.

[0039] In step S7, the system uses the current test program directory D:\ProductionOI\programs\TestPgm_V1.0\ as the compression source and the temporary compressed file storage path D:\ProductionOI\programs\a1b2c3d4e5f6\TestPgm_V1.0.zip as the compression target, and performs an archive compression operation. The system compresses the entire contents of the program directory into a temporary compressed file and stores this temporary compressed file in the temporary compressed file storage path. During the archive compression operation, the system continuously monitors the process liveness status of the compression process. If an interruption event causing abnormal termination of the compression process is captured, the system obtains the interruption location information corresponding to the interruption event, records the interruption location information to the error log, identifies the partially generated compressed files in the temporary storage space based on the interruption location information, performs deletion operations on the partially compressed files, restores the temporary storage space to its initial state before the archive compression operation, and terminates the current write-back process. The technical effect of this abnormal interruption handling mechanism is that when the compression process is interrupted due to insufficient system resources, insufficient storage space, or other abnormal reasons, the system can automatically clean up incomplete compressed files, avoiding the accumulation of junk files that lead to wasted storage space and interference with subsequent operations.

[0040] After executing step S8 and successfully completing the archive compression operation, the system confirms that the temporary compressed package is in a fully readable state at its storage path D:\ProductionOI\programs\a1b2c3d4e5f6\TestPgm_V1.0.zip. The system also confirms that the original compressed package is in a writable state at its original storage path D:\ProductionOI\programs\TestPgm_V1.0.zip, not occupied by the operating system. After confirming that both conditions are met, the system calls the atomic path redirection interface of the underlying file system. Through this interface, the system redirects the temporary compressed package's storage path D:\ProductionOI\programs\a1b2c3d4e5f6\TestPgm_V1.0.zip. m_V1.0.zip is redirected to the original storage path of the original compressed package, D:\ProductionOI\programs\TestPgm_V1.0.zip. During the redirection process, a replacement strategy that overwrites existing files is enabled. This atomic path redirection operation is executed at the underlying file system level as a single file system operation transaction, so that the original compressed package is completely replaced by a temporary compressed package in a single operation. The technical effect of this atomic replacement mechanism is that the entire replacement process is indivisible at the file system level, and there is no possibility of interruption during the replacement process. This completely eliminates the risk of corruption of the original compressed package due to interruption of the replacement operation in the traditional overwrite method. After the atomic replacement is completed, the file content under the original compressed package path has been updated to the compressed package content containing the new batch identifier LOT20260622001.

[0041] After executing step S9 and completing the atomic path redirection operation, the system removes the temporary storage space D:\ProductionOI\programs\a1b2c3d4e5f6\ and all files within it, completing the entire write-back process. At this point, the Code value in the verification configuration file CheckSum.ini in the original compressed package TestPgm_V1.0.zip has been successfully updated to the current batch identification code LOT20260622001. This update process does not involve any manual operation, achieving a fully automated configuration update.

[0042] Taking customers in region T05 as an example, the complete execution process described in this embodiment fully verifies the feasibility and effectiveness of the present invention in the semiconductor test procedure management scenario. By performing pre-verification for customer adaptation, unnecessary write-back operations are avoided for customers who do not need verification, saving test preparation time. By streaming line-by-line reading and in-situ field value replacement, the accurate modification of the configuration file content is ensured without destroying the original format. By creating an independent temporary storage space and atomic path redirection, the original compressed package is ensured to remain undamaged under any abnormal conditions during the write-back process. By handling abnormal interruptions and format preservation, the robustness and reliability of the write-back process are further improved. The method steps in this embodiment are interlocked, and the steps are logically linked through intermediate states such as configuration update flags and compressed package write-back process triggers, forming a complete automated configuration update and atomic write-back technical solution.

[0043] Example 3 This embodiment takes a scenario where multiple test machines concurrently execute test tasks, and the client code corresponding to some of the tasks does not require verification code modification as an example, to provide a detailed explanation of the technical implementation details and logical derivation effects of the client adaptation mechanism, streaming reading and format preservation mechanism, and atomic replacement result confirmation mechanism in this invention.

[0044] The first test machine is set to receive a test task with customer code T05 and batch identification code LOT20260622002; the second test machine receives a test task with customer code T07 and batch identification code LOT20260622003. Both test tasks trigger the configuration verification process simultaneously. The system's internally maintained set of compatible customers has three preset customer identification codes: T05, T06, and S01_TL.

[0045] For the test task of the first test machine, the system executes step S1, extracting the customer identification code T05 and batch identification code LOT20260622002 from the test task context. The system performs string equality comparisons between customer identification code T05 and each preset customer identification code in the compatible customer set. If the comparison result is that T05 is equal to the preset customer identification code T05, then customer identification code T05 matches the compatible customer set. The system generates an adaptation pass flag and activates the subsequent configuration update steps. For the test task of the second test machine, the system extracts the customer identification code T07 and compares it with T05, T06, and S01_TL in the compatible customer set in sequence. If T07 matches the above three... Since the preset identification codes are all unequal, the system determines that customer identification code T07 does not match the adapted customer set, terminates the current configuration verification process, and does not perform any subsequent file reading, modification, compression, or write-back operations. The technical effect of this customer adaptation mechanism is that for test tasks corresponding to customer codes that do not require verification code verification, the system terminates the process at the very beginning of the configuration verification process, avoiding unnecessary input / output overhead and time consumption caused by subsequent file operations, thus improving test preparation efficiency. At the same time, this mechanism, by centrally maintaining the adapted customer set, allows the strategy adjustment to be achieved simply by updating the customer identification codes in this set when the customer's requirement for verification code verification changes, without modifying the code logic.

[0046] For the first test machine, the subsequent steps are executed. When executing steps S2 to S3, the system opens the verification configuration file in a streaming mode. In this embodiment, the verification configuration file contains relatively complex configuration entries. In addition to the Code field, it also contains comment lines and blank lines. The exemplary content of the verification configuration file is as follows: the first line is a comment line; CheckSum configuration file, the second line is a blank line, the third line is CheckSumVersion=1.0, the fourth line is Code=LOT20260622000, the fifth line is CheckSumEnable=True, and the sixth line is a comment line; do not modify belowlines. The system opens the byte input stream of the file in UTF-8 encoding format and reads it byte by byte starting from the beginning. When a line terminator is encountered, all the bytes read before are extracted as complete configuration entries. The technical effect of this streaming mode is that the system does not need to load the entire configuration file into memory at once, but reads and processes it line by line. Therefore, no matter how large the configuration file is, the memory resources occupied by the system are always kept at a low and stable level, avoiding memory overflow due to the large configuration file.

[0047] During step S4, the system performs field prefix matching on each extracted configuration entry. For comment lines and blank lines, since their starting fields do not match the checksum field identifier Code=, the system skips these configuration entries. When processing the fourth line, Code=LOT20260622000, the system identifies this configuration entry as the target configuration entry. The system locates the equals sign within the string range of the target configuration entry and replaces the original field value LOT20260622000 in the field value range after the equals sign with the batch identification code LOT20260622002. This replacement operation is only performed on the specific field value range of the target configuration entry and does not affect the Code= prefix or the line indentation character of the configuration entry. The system writes all configuration entries after the replacement operation into the cache container in the original reading order, that is, the cache container stores them sequentially. The system preserves comment lines, blank lines, `CheckSumVersion=1.0`, `Code=LOT20260622002`, `CheckSumEnable=True`, and other elements. When reconstructing the file content, the system does not append a newline character to the first configuration entry (comment line) in the cache container, but inserts newline characters between adjacent configuration entries. This completely preserves the comment lines, blank lines, and the relative order and line structure of each configuration entry in the original configuration file. The technical effect of this format preservation process is that the original comment information, blank line format, and arrangement order of each configuration entry in the verification configuration file are completely preserved. Although these non-functional contents do not affect the parsing results of the configuration file, they have important readability reference value for maintenance personnel. Keeping these contents unchanged avoids operators from making additional manual adjustments to the configuration file, further improving the integrity of the automated process.

[0048] Execute steps S5 to S7 to complete the configuration file write-back and temporary compressed package creation.

[0049] When executing step S8, the system calls the atomic path redirection interface of the underlying file system to complete the atomic replacement. After the atomic replacement is completed, the system executes the atomic replacement result confirmation process. The system reads the file attribute information of the original compressed package in the original storage path. This file attribute information includes the file size, file modification timestamp, and file system inode identifier. The system obtains the historical file attribute information of the temporary compressed package before the atomic path redirection operation. The system performs a consistency check between the file attribute information of the original compressed package and this historical file attribute information. If the file size, file modification timestamp, and file system inode identifier all match, the system confirms that the atomic path redirection operation is successful and generates an operation success confirmation record, which is written to the log. The technical effect of this atomic replacement result confirmation mechanism is that, through comprehensive verification of three dimensions—file size, file modification timestamp, and file system inode identifier—the system can confirm that the atomic replacement operation has been successfully completed from three levels: file content integrity, file version timeliness, and file system storage location consistency. The operation success confirmation record recorded in the log provides a reliable data source for subsequent audit tracing. When it is necessary to trace historical operations, maintenance personnel can verify whether the update operation of a specific batch of compressed packages has been successfully executed by querying the confirmation record in the log.

[0050] Taking the comparison of processing results of customer codes T05 and T07 on different test machines as an example, this embodiment further verifies the customer adaptability and the sophistication of the technical means of the present invention. For customer code T05 in the customer set, the system fully executes the entire process of configuration verification, streaming reading, in-situ replacement, format preservation, independent temporary space compression, atomic path redirection, and replacement result confirmation. For customer code T07 outside the customer set, the system terminates the process during the customer adaptation stage and does not perform any subsequent operations. This on-demand execution technical solution has significant technical effects in semiconductor test factories with a large number of different customer codes, avoiding unnecessary time waiting for all customers caused by uniform mandatory check code modification.

[0051] The streaming reading and format preservation mechanism described in this embodiment further yields the following technical effects: Since the original format of the verification configuration file is completely preserved, the test machine will not trigger parsing exceptions or reading failures due to format changes when loading the configuration file. Since the in-place field value replacement method only performs operations on the range of check code field values, the other character content in the configuration entries remains unchanged. The accuracy of this operation avoids unexpected changes in spaces or tabs that may be introduced by replacing the entire line, further ensuring the correctness of the configuration file parsing.

[0052] The atomic substitution result confirmation mechanism described in this embodiment further derives the following technical effects: file size verification in file attribute information can eliminate the risk of incomplete compressed package content or data loss; file modification timestamp verification can confirm that the compressed package version has been updated to the current time point rather than remaining in a historical version; file system inode identifier verification can confirm that the compressed package's storage location in the file system has been correctly switched to the original path rather than remaining in a temporary path. The verification results of the three dimensions corroborate each other and together constitute a complete operation result confirmation system.

[0053] This embodiment takes a scenario with multiple test machines running concurrently and a complex configuration file containing comment lines and blank lines as an example to fully demonstrate the execution process of the technical solution and the technical effects derived from the logical deduction in a practical application scenario. It fully verifies the practical value and reliability of the present invention in the field of semiconductor test program management.

[0054] The above are all preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Therefore, all equivalent changes made in accordance with the structure, shape and principle of the present invention should be covered within the scope of protection of the present invention.

Claims

1. An embedded configuration update and compressed package atomic write-back method, characterized in that, Includes the following steps: S1: In response to the configuration verification process triggered by the current test task, obtain the customer identification code and batch identification code corresponding to the current test task, and perform a matching operation on the customer identification code according to the preset adapted customer set; if the customer identification code matches the adapted customer set, execute the subsequent configuration update steps; S2: Based on the target storage path and program name of the current test program, construct the complete access path of the verification configuration file, and perform an existence probe on the complete access path to confirm the existence status of the verification configuration file in the storage medium; S3: After confirming that the verification configuration file exists, open the verification configuration file in streaming mode and extract each configuration entry one by one according to the physical storage order of the configuration entries; S4: Perform a field prefix matching operation on the starting field of each extracted configuration entry to identify whether the configuration entry carries a checksum field identifier; when a target configuration entry carrying a checksum field identifier is identified, replace the original checksum field value in the target configuration entry with a batch identifier, and activate the configuration update flag; write all configuration entries after the replacement operation into the cache container in the original reading order, and when reconstructing the contents of the cache container into the target file content, perform the process of not appending a newline character on the first configuration entry in the cache container, and insert a newline character between adjacent configuration entries; S5: When the configuration update flag is active, write back the contents of the target file in the cache container to the verification configuration file to trigger the compressed package write-back process; S6: After the compressed package write-back process is triggered, a temporary storage space independent of the original compressed package storage path is created in the storage root directory where the target storage path is located, and a temporary compressed package storage path is established in the temporary storage space. S7: Using the current test program directory as the compression source and the temporary compressed package storage path as the compression target, perform an archive compression operation to compress the program directory into a temporary compressed package and store the temporary compressed package in the temporary compressed package storage path. S8: After confirming that the temporary compressed package is in a fully readable state, call the atomic path redirection interface of the underlying file system to redirect the storage path of the temporary compressed package to the original storage path of the original compressed package. During the redirection process, enable the replacement strategy of overwriting existing files so that the original compressed package is completely replaced by the temporary compressed package in a single file system operation transaction. S9: Remove temporary storage space after the atomic path redirection operation is completed.

2. The method according to claim 1, characterized in that, Step S6 involves creating a temporary storage space independent of the original compressed file storage path in the root directory of the target storage path. This step includes the following sub-steps: Generate a universally unique identifier in the storage root directory. The universally unique identifier has a one-to-one correspondence with the current write-back process. Using a universally unique identifier as the temporary directory name, a temporary directory creation operation is performed in the storage root directory to form a temporary directory that can only be exclusively accessed by the current write-back process; Obtain the filename of the original compressed package, and concatenate the filename with the path of the temporary directory within the temporary directory to form the temporary compressed package storage path. The temporary compressed package storage path and the original storage path of the original compressed package are independent of each other at the file system level.

3. The method according to claim 1, characterized in that, Step S5, which involves writing back the target file content from the cache container to the verification configuration file, specifically includes the following sub-steps: Open the file output stream corresponding to the verification configuration file, and apply an exclusive write lock to the verification configuration file while the file output stream is open. The exclusive write lock is used to prevent other processes besides the current write-back process from accessing the verification configuration file during the write process. The contents of the target file in the cache container are written to the verification configuration file in a synchronous blocking manner through the file output stream. After the write operation is complete, release the exclusive write lock and close the file output stream, restoring the verification configuration file to a state accessible to other processes.

4. The method according to claim 1, characterized in that, Step S4, which replaces the original checksum field value in the target configuration entry with a batch identification code, specifically includes the following sub-steps: Locate the start and end positions of the checksum field within the string range of the target configuration entry; Extract the field value range defined by the start and end positions of the field, and remove all original field values ​​within the field value range; Write the batch identification code within the same field value range defined by the start and end positions of the field, keeping the remaining characters in the target configuration entry unchanged except for the check code field value.

5. The method according to claim 1, characterized in that, The archiving and compression operation in step S7 also includes an exception interruption handling process, which specifically includes the following sub-steps: Continuously monitor the process liveness status of the compression process during the archive compression operation; When an interrupt event of abnormal termination of the compression process is captured during the monitoring process, the interrupt location information corresponding to the interrupt event is obtained and the interrupt location information is recorded in the error log; Based on the interruption location information, identify the partially generated compressed files in the temporary storage space, perform deletion operations on the partially compressed files, restore the temporary storage space to its initial state before the archive compression operation, and terminate the current write-back process.

6. The method according to claim 1, characterized in that, Step S3 involves opening the verification configuration file in streaming mode and extracting each configuration entry one by one according to the physical storage order of the configuration entries. Specifically, this includes the following sub-steps: Using the file encoding format of the verification configuration file as the parsing benchmark, open the byte input stream corresponding to the verification configuration file; Read byte by byte starting from the beginning of the byte input stream. When a line terminator is encountered, extract all bytes read before the line terminator as a complete configuration entry. After extracting the current configuration entry, continue reading from the beginning of the next byte of the byte input stream, repeating the configuration entry extraction operation until the end of the byte input stream is reached.

7. The method according to claim 1, characterized in that, After step S8 calls the atomic path redirection interface of the underlying file system to redirect the storage path of the temporary compressed package to the original storage path of the original compressed package, the process also includes an atomic replacement result confirmation process, which specifically includes the following sub-steps: Read the file attribute information of the original compressed package in the original storage path. The file attribute information includes file size, file modification timestamp, and file system inode identifier. Obtain the historical file attribute information of the temporary compressed package before the atomic path redirection operation is executed, and perform a consistency check between the file attribute information of the original compressed package and the historical file attribute information; If the file size, file modification timestamp, and file system inode identifier all match, confirm that the atomic path redirection operation was successful and generate a success confirmation record to be written to the log.

8. The method according to claim 1, characterized in that, Step S1 involves performing a matching operation on the customer identification code based on a preset set of compatible customers, specifically including the following sub-steps: Extract each preset customer identification code sequentially from the preset set of compatible customers; Perform a string equality comparison between the customer identification code and the currently extracted preset customer identification code; If the customer identification code is equal to any one of the preset customer identification codes, it is determined that the customer identification code matches the set of suitable customers, and an adaptation pass flag is generated. The adaptation pass flag is used to enable the execution of subsequent configuration update steps. If the customer identification code is not equal to any of the preset customer identification codes, it is determined that the customer identification code does not match the set of suitable customers, and the current configuration verification process is terminated.

9. An embedded configuration update and compressed package atomic write-back system, used to execute the method of any one of claims 1-8, characterized in that, include: The customer adaptation trigger module is used to respond to the configuration verification process triggered by the current test task, obtain the customer identification code and batch identification code corresponding to the current test task, and perform a matching operation on the customer identification code according to the preset adapted customer set; if the customer identification code matches the adapted customer set, the subsequent configuration update process is triggered. The path construction and detection module is used to construct the complete access path of the verification configuration file based on the target storage path and program name where the current test program is located, and to perform an existence detection on the complete access path to confirm the existence status of the verification configuration file in the storage medium. The streaming read module is used to open the verification configuration file in streaming mode after confirming that the verification configuration file exists, and extract each configuration entry one by one according to the physical storage order of the configuration entries. The configuration entry replacement and format preservation module performs a field prefix matching operation on the starting field of each extracted configuration entry to identify whether the configuration entry carries a checksum field identifier. When a target configuration entry carrying a checksum field identifier is identified, the original checksum field value in the target configuration entry is replaced with a batch identifier, and a configuration update flag is activated. All configuration entries after the replacement operation are written to a cache container in the original reading order. When reconstructing the contents of the cache container into the target file content, the first configuration entry in the cache container is processed to not add a newline character, and a newline character is inserted between adjacent configuration entries. When the configuration update flag is active, the contents of the target file in the cache container are written back to the verification configuration file to trigger the compressed package write-back process; The temporary space creation module is used to create a temporary storage space independent of the original compressed package storage path in the storage root directory where the target storage path is located after the compressed package write-back process is triggered, and to establish a temporary compressed package storage path in the temporary storage space. The archive compression execution module is used to perform archive compression operations with the current test program directory as the compression source and the temporary compressed package storage path as the compression target, compressing the program directory into a temporary compressed package and storing the temporary compressed package in the temporary compressed package storage path; The atomic path redirection module is used to call the atomic path redirection interface of the underlying file system after confirming that the temporary compressed package is in a completely readable state, redirect the storage path of the temporary compressed package to the original storage path of the original compressed package, and enable the replacement strategy of overwriting existing files during the redirection process, so that the original compressed package is completely replaced by the temporary compressed package in a single file system operation transaction. The space reclamation module is used to remove temporary storage space after an atomic path redirection operation is completed.

10. The system according to claim 9, characterized in that, The system also includes: The write lock control module is used to open the file output stream corresponding to the verification configuration file during the process of the configuration entry replacement and format preservation module writing back the target file content in the cache container to the verification configuration file. During the opening of the file output stream, an exclusive write lock is applied to the verification configuration file. The exclusive write lock is used to prevent other processes besides the current write-back process from accessing the verification configuration file during the write process. The target file content in the cache container is written to the verification configuration file in a synchronous blocking manner through the file output stream. After the write operation is completed, the exclusive write lock is released and the file output stream is closed, so that the verification configuration file is restored to a state accessible to other processes. The exception interruption handling module is used to continuously monitor the process life status of the compression process during the archiving and compression operation performed by the archiving and compression execution module; when an interruption event of abnormal termination of the compression process is captured during the monitoring process, the interruption location information corresponding to the interruption event is obtained and the interruption location information is recorded to the error log; based on the interruption location information, the module identifies some compressed files that have been generated in the temporary storage space, performs deletion operations on some compressed files, restores the temporary storage space to the initial state before the archiving and compression operation is performed, and terminates the current write-back process.

Images