Bug 13613 - Patch barfs on some cvs diffs
Summary: Patch barfs on some cvs diffs
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: patch (Show other bugs)
(Show other bugs)
Version: 6.2
Hardware: All Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-07-08 22:57 UTC by Chris Seawood
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-10-03 12:44:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Use Index: to determine name if POSIXLY_CORRECT & Index: are used. (920 bytes, patch)
2000-07-08 23:12 UTC, Chris Seawood
no flags Details | Diff
I've found a test case. (474 bytes, text/plain)
2000-10-03 12:44 UTC, Tim Waugh
no flags Details

Description Chris Seawood 2000-07-08 22:57:35 UTC
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.

Comment 1 Chris Seawood 2000-07-08 23:12:11 UTC
Created attachment 961 [details]
Use Index: to determine name if POSIXLY_CORRECT & Index: are used.

Comment 2 Trond Eivind Glomsrxd 2000-07-12 17:02:06 UTC
Is this still a problem with patch 2.5.4?

Comment 3 Chris Seawood 2000-07-12 17:34:07 UTC
Yes, patch 2.5.4 exhibits the same behavior.

Comment 4 Chris Seawood 2000-07-12 17:41:33 UTC
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.

Comment 5 Trond Eivind Glomsrxd 2000-07-12 18:01:16 UTC
Can you attach a testcase?

Comment 6 Trond Eivind Glomsrxd 2000-07-25 17:13:35 UTC
Do you have a testcase?

Comment 7 Tim Waugh 2000-10-03 12:44:38 UTC
Created attachment 3659 [details]
I've found a test case.

Comment 8 Tim Waugh 2000-10-03 13:23:51 UTC
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.

Comment 9 Tim Waugh 2000-10-03 13:37:18 UTC
I'm wrong.  Single UNIX is just as bad, and will check for non-Index: names

Comment 10 Tim Waugh 2000-10-04 16:38:27 UTC
Incidentally, cvs-1.10.8-8 generates patches (from 'cvs diff') that don't have
this problem.

Note You need to log in before you can comment on or make changes to this bug.