Bug 13613 - Patch barfs on some cvs diffs
Patch barfs on some cvs diffs
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: patch (Show other bugs)
6.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-07-08 18:57 EDT by Chris Seawood
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-10-03 08:44:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 19:12 EDT, Chris Seawood
no flags Details | Diff
I've found a test case. (474 bytes, text/plain)
2000-10-03 08:44 EDT, Tim Waugh
no flags Details

  None (edit)
Description Chris Seawood 2000-07-08 18:57:35 EDT
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 19:12:11 EDT
Created attachment 961 [details]
Use Index: to determine name if POSIXLY_CORRECT & Index: are used.
Comment 2 Trond Eivind Glomsrxd 2000-07-12 13:02:06 EDT
Is this still a problem with patch 2.5.4?
Comment 3 Chris Seawood 2000-07-12 13:34:07 EDT
Yes, patch 2.5.4 exhibits the same behavior.

Comment 4 Chris Seawood 2000-07-12 13:41:33 EDT
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 14:01:16 EDT
Can you attach a testcase?
Comment 6 Trond Eivind Glomsrxd 2000-07-25 13:13:35 EDT
Do you have a testcase?
Comment 7 Tim Waugh 2000-10-03 08:44:38 EDT
Created attachment 3659 [details]
I've found a test case.
Comment 8 Tim Waugh 2000-10-03 09:23:51 EDT
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 09:37:18 EDT
I'm wrong.  Single UNIX is just as bad, and will check for non-Index: names
first.
Comment 10 Tim Waugh 2000-10-04 12:38:27 EDT
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.