bug: duplicate entry name causes "File exists" abort instead of graceful skip

[bug-ops]

Summary

When a TAR archive contains two entries with the same path (e.g. a hardlink entry followed by a plain file, or two plain files), exarch aborts the entire extraction with File exists (os error 17) instead of skipping the conflicting entry.

Reproduction

Archive contains (in order):

1. legit.txt — regular file, content legit
2. link_to_legit — regular file, content OVERWRITTEN
3. link_to_legit — hardlink to legit.txt

Extraction without --force:

Error: File exists (os error 17)
WARNING: Extraction was stopped. 2 items (2 files, 0 directories, 0 symlinks) were written to disk before the error.

Expected behavior

Conflicting duplicate entry should be skipped (with a warning in the report) rather than aborting the entire extraction.

Actual behavior

Extraction aborts on the first duplicate entry. Partial extraction leaves the destination in an inconsistent state.

Severity

Medium — affects archives created by tools that produce duplicate entries (e.g. some tar implementations with metadata entries). Not a security escape, but a reliability issue.

Notes

With --force, exarch would overwrite, which may be the desired behavior. The issue is that without --force, there is no graceful fallback — just an abort.

[bug-ops]

Clarification: EEXIST comes only from hard_link(), not duplicate plain files

Further investigation (session 027–028) reveals:

• create_file_with_mode uses OpenOptions::create(true).truncate(true) — this is O_CREAT | O_TRUNC, which silently overwrites duplicate plain file entries. No EEXIST.
• hard_link(target, link) fails with EEXIST if link already exists. Unlike file creation, hard_link cannot overwrite an existing path — the existing file must be removed first.

Actual failure scenario

1. Archive entry order: legit.txt (file) → link_to_legit (hardlink) → link_to_legit (plain file)
2. Two-pass extraction:
   • Pass 1: legit.txt written, link_to_legit plain file written
   • Pass 2: hard_link("legit.txt", "link_to_legit") → EEXIST → abort

Proposed fix scope

The fix is narrower than originally stated: handle ErrorKind::AlreadyExists from hard_link() in the second pass. Options:

1. Skip: if link_path already exists as a regular file, skip the hardlink creation and emit a warning in the report
2. Remove and re-link: unlink the existing file and create the hardlink (more semantically correct but potentially dangerous if the existing file has user data)

Option 1 (skip) is safer and aligns with the security-first principle.

[bug-ops]

Resolved by PR #134: replacing fs::hard_link with fs::copy in the second extraction pass eliminates the EEXIST error. fs::copy overwrites the existing file rather than failing. Extraction now completes successfully (exit 0, 3 files).