Behavior of OpenCV FileStorage APPEND mode during retry after transient I/O failure

Goal: Use OpenCV’s FileStorage with the APPEND flag to safely retry a write operation after a temporary I/O error without duplicating previously written nodes.

Constraints: The application must detect a failed << operation or open() call, decide whether to reopen the storage in APPEND mode, and rely on the flag to position the file pointer at the end of the existing XML/YAML file. Uncertainty remains about whether a retry after a partial write could leave an incomplete node that causes duplication or malformed content on subsequent attempts, and whether the APPEND flag alone guarantees idempotent retries when the same logical data is written again.

Specific questions:

• Does reopening a FileStorage in APPEND mode after a failed write guarantee that the file pointer is correctly positioned at the end of the last successfully written node, even if the failure occurred mid‑node?
• If the same key‑value pair is written again during a retry, will APPEND produce duplicate nodes, and how should applications avoid or detect such duplication?
• Are there any version‑specific behaviors (e.g., OpenCV 2.4 vs 4.x) that affect the reliability of APPEND-based retry logic?