Fix intermittent VCI signature failure in cart coherency MAM

[implr]

tape_set_cart_coherency() builds the Volume Coherency Information MAM parameter in an uninitialized stack buffer and writes byte 36 (the byte right after the 4-char "LTFS" signature) nowhere. The signature is copied with arch_strncpy(coh_data + 32, "LTFS", 5, 4), which on POSIX is strncpy(dst, "LTFS", 4); since the count equals strlen("LTFS"), no terminating NUL is written, leaving byte 36 as uninitialized stack data.

tape_get_cart_coherency() validates the signature with strncmp(coh_data + 32, "LTFS", sizeof("LTFS")), i.e. 5 bytes, so it requires byte 36 to be 0x00. When the leftover stack byte happens to be non-zero, the read-back fails with LTFS12062W, the coherency data for the partition is discarded (LTFS11016W/LTFS11017W), and the next mount falls back to a full medium consistency check. Because the value depends on stack contents at write time, the failure is intermittent.

This was introduced in commit 1f1ee3c (#575), which replaced the previous NUL-terminating copy with the 4-byte strncpy. Windows is unaffected because arch_strncpy maps to strncpy_s, which NUL-terminates.

Zero the buffer before populating it so byte 36 (and any other gap) is deterministic, restoring a valid signature on the medium.

Claude-Session: https://claude.ai/code/session_01PqvvYQzkFL6nNFgbJ9kSuq

Summary of changes

This pull request includes following changes or fixes.

• Fix of issue #issue_no
• Add foo
• Change bar

Description

Please include relevant motivation and context. List any dependencies that are required for this change.

Fixes #issue_no

Type of change

Please delete items that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have confirmed my fix is effective or that my feature works

[vandelvan]

Thanks for reporting Claude's finding, we'll go with @Piloalucard 's approach on PR #624

This issue could have been a good learning experience and good first issue for human committers to get a PR merged, Gen AI tools can be great to do these sort of findings but there is no experience earned if you let it do all the work.

Kindly complete the PR Template for the next time.

[implr]

Ouch, I did not intend to submit this without de-sloppifying it first, it was an accident. Sincere apologies for wasting your time.

[vandelvan]

@implr

No worries at all, and sorry if my message seemed a bit harsh.

de-sloppifying

I'm gonna start using that term haha! please consider contributing with de-sloppified PRs 😄