The question

When a multi-source install command backs up a destination, fails to copy one source, then sees another source with the same name, which state owns the path?

Working model

There are two nearby but independent machines.

Invocation ownership asks whether an earlier operand completed its data-copy phase for this destination. Only a completed copy owns the name; a source-stat failure, no-op comparison, or failed copy does not.

Backup transaction asks whether the old destination was moved aside and the replacement copy committed. If the backup exists but the copy fails, remove any partial destination and restore the backup. Failures after a completed copy do not roll the old file back.

The useful boundary is the commit event—not the function's final success boolean.

Provenance

Synthesized from black-box GNU install behavior and controlled uutils work recorded at Linux Fieldwork revision c79d34b65fb2cd8c54234f361f073248c53b513a. It is a design model, not an upstream acceptance claim.

Trace it

Start with dest/file = original. Source A fails during data copy; source B later succeeds to the same name.

Draw both machines separately and mark these events:

• old destination renamed to backup;
• A begins, then fails;
• partial A removed;
• backup restored;
• B copies successfully.

The expected end state is dest/file = B and dest/file~ = original. Explain why marking A as an owner would produce the wrong answer.