Most cvs diff headers look something like: Index: caps/src/Makefile.in =================================================================== RCS file: /cvsroot/mozilla/caps/src/Makefile.in,v retrieving revision 1.32 diff -u -r1.32 Makefile.in --- Makefile.in 2000/05/14 10:38:48 1.32 +++ Makefile.in 2000/05/16 02:59:30 Since cvs does a relative diff against the file in question, the new & old names only contain the basename of the file. In order for patch to see the relative path set in Index:, you must set the POSIXLY_CORRECT env variable. This is where things get weird. From the patch manpage: 7 If there is an Index: line in the leading garbage and if either the old and new names are both absent or the POSIXLY_CORRECT environment variable is set, patch takes the name in the Index: line. 7 For the purpose of the following rules, the names are considered to be in the order (old, new, index), regardless of the order that they appear in the header. 7 If some of the named files exist, patch uses the first name if the POSIXLY_CORRECT environment variable is set, and the best name otherwise. The problem is that if you already have a file with the same base name in the toplevel directory, patch will use that file instead. In the above example, I had to remove the toplevel Makefile.in before that patch would work. I think that if POSIXLY_CORRECT is set, patch should use the name from Index: regardless of the settings of old, new & a file with the same name in the current directory.
Created attachment 961 [details] Use Index: to determine name if POSIXLY_CORRECT & Index: are used.
Is this still a problem with patch 2.5.4?
Yes, patch 2.5.4 exhibits the same behavior.
Oh, and as a sidenote, it only appears to occur with multi-file patches. If I attempt to patch just caps/src/Makefile.in, patch works fine as is.
Can you attach a testcase?
Do you have a testcase?
Created attachment 3659 [details] I've found a test case.
Patch is acting according to POSIX. The bug is in the POSIX spec. :-(( The Single Unix Spec seems to be better here, but it hardly seems fair to follow that behaviour while POSIXLY_CORRECT is set. Fixing this requires new options to patch I think.
I'm wrong. Single UNIX is just as bad, and will check for non-Index: names first.
Incidentally, cvs-1.10.8-8 generates patches (from 'cvs diff') that don't have this problem.