"Old" filename in patch files generated for testing does not exist and can cause failures

[marc-hb]

Most patch files generated for testing start like this:

--- a/alef	2026-05-05 17:02:25.388687288 -0400
+++ target/unified-diff//alef	2026-05-05 17:02:25.388687288 -0400
...

Note patch does not use TWO filenames; it uses only one name because it patches files "in place". But patch input == diff output and it makes sense for diff output to have "old" and "new" filenames.

a/alef does not normally not exist and tests normally pass because GNU patch silently falls back on the "new" filename. Except when a/alef exists, and then the corresponding test(s) to fail.

https://www.gnu.org/software/diffutils/manual/html_node/Multiple-Patches.html documents GNU precedence and that the "old" file name has precedence over the "new" filename.

Trivial reproduction:

cd diffutils
mkdir a
touch a/alef  a/alefn  a/alef_  a/alefx  a/alefr  a/fuzz.file
cargo test


---- context_diff::tests::test_permutations stdout ----

thread 'context_diff::tests::test_permutations' (98977) panicked at src/context_diff.rs:458:33:
Output { status: ExitStatus(unix_wait_status(256)), stdout: "patching file a/alef\nHunk #1 FAILED at 1.\n1 out of 1 hunk FAILED -- saving rejects to file a/alef.rej\n", stderr: "" }

I hit this problem because some other (and unfortunately unknown) test issue left bogus a/alef* file(s) behind in my workspace. I didn't bother cleaning them up because I assumed some test would keep recreating them - and that cost me a lot of time.