Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 13613

Summary: Patch barfs on some cvs diffs
Product: [Retired] Red Hat Linux Reporter: Chris Seawood <cls>
Component: patchAssignee: Tim Waugh <twaugh>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2CC: aleksey
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-10-03 12:44:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Use Index: to determine name if POSIXLY_CORRECT & Index: are used.
none
I've found a test case. none

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
first.

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.